Jenkins에서의 이전 작업
Jenkins에서 GitLab CI/CD로 이전하는 경우, Jenkins 워크플로우를 복제하고 향상시키는 CI/CD 파이프라인을 생성할 수 있습니다.
주요 유사성 및 차이점
GitLab CI/CD와 Jenkins는 몇 가지 유사성을 갖는 CI/CD 도구입니다. GitLab과 Jenkins은 모두:
- 작업의 모음에 대한 스테이지를 사용합니다.
- 컨테이너 기반 빌드를 지원합니다.
둘 사이에 중요한 차이점도 있습니다:
- GitLab CI/CD 파이프라인은 모두 YAML 형식의 구성 파일로 구성됩니다. Jenkins는 그루비 형식의 구성 파일(선언적 파이프라인) 또는 Jenkins DSL(스크립트 파이프라인)을 사용합니다.
- GitLab은 SaaS(클라우드) 또는 Self-Managed형 배포 모두에서 실행할 수 있습니다. Jenkins 배포는 Self-Managed형해야 합니다.
- GitLab은 기본적으로 원격 리포지터리를 위한 소스 코드 관리(SCM)를 제공합니다. Jenkins는 코드를 저장하기 위한 별도의 SCM 솔루션이 필요합니다.
- GitLab은 내장 컨테이너 레지스트리를 제공합니다. Jenkins는 컨테이너 이미지를 저장하기 위한 별도의 솔루션이 필요합니다.
- GitLab은 코드 검사를 위한 내장 템플릿을 제공합니다. Jenkins는 코드 검사를 위해 3rd party 플러그인이 필요합니다.
기능 및 컨셉 비교
많은 Jenkins 기능과 개념에는 동일한 기능을 제공하는 GitLab과의 동등한 것들이 있습니다.
구성 파일
Jenkins는 Groovy 형식의 Jenkinsfile
로 구성할 수 있습니다. GitLab CI/CD는 기본적으로 .gitlab-ci.yml
파일을 사용합니다.
Jenkinsfile
예시:
pipeline {
agent any
stages {
stage('hello') {
steps {
echo "Hello World"
}
}
}
}
해당 GitLab CI/CD .gitlab-ci.yml
파일은:
stages:
- hello
hello-job:
stage: hello
script:
- echo "Hello World"
Jenkins 파이프라인 구문
Jenkins 구성은 “섹션”과 “지시문”을 사용한 pipeline
블록으로 구성됩니다. GitLab CI/CD는 유사한 기능을 갖고 있으며, YAML 키워드로 구성됩니다.
섹션
Jenkins | GitLab | 설명 |
---|---|---|
agent
| image
| Jenkins 파이프라인은 에이전트에서 실행되며, agent 섹션은 파이프라인 실행 방법과 사용할 도커 컨테이너를 정의합니다. GitLab 작업은 _러너(runner)_에서 실행되며, image 키워드는 사용할 컨테이너를 정의합니다. Kubernetes나 호스트에서 자체 러너를 구성할 수 있습니다.
|
post
|
after_script 또는 stage
| Jenkins post 섹션은 스테이지나 파이프라인이 끝날 때 수행해야 하는 작업을 정의합니다. GitLab에서는 after_script 을 사용하여 작업 후에 실행할 명령을 정의하고, before_script 은 작업 내의 다른 명령보다 먼저 실행할 작업을 정의합니다. stage 은 작업이 실행될 정확한 스테이지를 선택하는 데 사용됩니다. GitLab은 항상 모든 다른 정의된 스테이지보다 항상 먼저 또는 나중에 실행되는 .pre 및 .post 스테이지도 지원합니다.
|
stages
| stages
| Jenkins 스테이지는 작업의 그룹입니다. GitLab CI/CD도 스테이지를 사용하지만 더 유연합니다. 각각에 여러 독립적인 작업을 갖는 여러 스테이지를 가질 수 있습니다. 최상위에서 stages 를 사용하여 스테이지와 실행 순서를 정의하고, 작업 수준에서 stage 를 사용하여 해당 작업의 스테이지를 정의합니다.
|
steps
| script
| Jenkins의 steps 는 실행할 작업을 정의합니다. GitLab CI/CD는 유사한 script 섹션을 사용합니다. script 섹션은 각 명령을 순차적으로 실행하는 YAML 배열입니다.
|
지시문
Jenkins | GitLab | 설명 |
---|---|---|
environment
| variables
| Jenkins는 환경 변수에 environment 를 사용합니다. GitLab CI/CD는 variables 키워드를 사용하여 작업 실행 중에 사용할 수 있는 CI/CD 변수를 정의하며, 더 동적인 파이프라인 구성에도 사용됩니다. 이러한 변수는 GitLab UI의 CI/CD 설정에서 설정할 수도 있습니다.
|
options
| 해당 없음 | Jenkins는 추가 구성에 options 를 사용하며, 이는 타임아웃 및 재시도 값 등을 포함합니다. GitLab은 추가 섹션이 필요 없으며 모든 구성은 작업 또는 파이프라인 수준의 CI/CD 키워드로 추가됩니다. 예를 들어 timeout 또는 retry 가 있습니다.
|
parameters
| 해당 없음 | Jenkins에서는 파이프라인을 트리거할 때 파라미터를 필수로 지정할 수 있습니다. GitLab에서는 프로젝트 설정, 런타임 중에 UI를 통해 매뉴얼으로 또는 API를 통해 파이프라인 구성을 포함하여 CI/CD 변수로 처리됩니다. |
triggers
| rules
| Jenkins에서 triggers 는 파이프라인을 다시 실행할 시기를 정의합니다. 예를 들어 cron 표기를 통해 정기적으로 실행할 수 있습니다. GitLab CI/CD는 Git 변경 및 Merge Request 업데이트를 포함한 여러 이유로 파이프라인을 자동으로 실행할 수 있습니다. rules 키워드를 사용하여 작업을 실행할 이벤트를 제어합니다. 정기적인 파이프라인은 프로젝트 설정에서 정의됩니다.
|
tools
| 해당 없음 | Jenkins에서 tools 는 환경에 추가 도구를 정의합니다. GitLab은 이와 유사한 키워드가 없으며, 권장사항은 작업에 필요한 정확한 도구가 포함된 사전 빌드된 컨테이너 이미지를 사용하는 것입니다. 이러한 이미지는 캐시될 수 있으며, 파이프라인에 이미 필요한 도구가 포함되도록 빌드될 수 있습니다. 작업이 추가 도구가 필요한 경우, 이러한 도구는 before_script 섹션의 일부로 설치할 수 있습니다.
|
input
| 해당 없음 | Jenkins에서 input 은 사용자 입력을 추가합니다. parameters 와 유사하게, GitLab에서는 CI/CD 변수를 통해 처리됩니다.
|
when
| rules
| Jenkins에서 when 은 스테이지를 실행해야 하는 시기를 정의합니다. GitLab에도 when 키워드가 있으며, 작업을 성공했는지 실패했는지에 따라 작업을 시작해야 하는지를 정의합니다. 특정 파이프라인에 작업을 추가할 때 rules 를 사용하여 제어합니다.
|
일반적인 구성
이 부분에서는 Jenkins에서 GitLab CI/CD로 변환할 수 있는 일반적으로 사용되는 CI/CD 구성에 대해 설명합니다.
Jenkins 파이프라인은 새로운 커밋이 푸시되는 등의 특정 이벤트가 발생할 때 트리거되는 자동화 CI/CD 작업을 생성합니다. Jenkins 파이프라인은 Jenkinsfile
에 정의됩니다. GitLab 상의 대응 파일은 .gitlab-ci.yml
구성 파일입니다.
Jenkins는 소스 코드를 저장하는 곳을 제공하지 않기 때문에 Jenkinsfile
을 별도의 소스 제어 리포지터리에 저장해야 합니다.
작업
작업은 특정 결과를 얻기 위해 일련의 명령을 순차적으로 실행합니다.
예를 들어, Jenkinsfile
에서 컨테이너를 빌드하고 프로덕션 환경에 배포하는 경우:
pipeline {
agent any
stages {
stage('build') {
agent { docker 'golang:alpine' }
steps {
apk update
go build -o bin/hello
}
post {
always {
archiveArtifacts artifacts: 'bin/hello'
onlyIfSuccessful: true
}
}
}
stage('deploy') {
agent { docker 'golang:alpine' }
when {
branch 'staging'
}
steps {
echo "Deploying to staging"
scp bin/hello remoteuser@remotehost:/remote/directory
}
}
}
}
위 예시:
-
golang:alpine
컨테이너 이미지를 사용합니다. - 코드를 빌드하는 작업을 실행합니다.
- 생성된 실행 파일을 artifact로 저장합니다.
- 커밋이
staging
브랜치를 대상으로 할 때만 존재하는 두 번째 작업을 배포합니다.- 빌드 스테이지가 성공한 후에 시작됩니다.
- 앞서의 작업에서 생성된 실행 파일 artifact를 사용합니다.
해당 GitLab CI/CD .gitlab-ci.yml
파일은:
default:
image: golang:alpine
stages:
- build
- deploy
build-job:
stage: build
script:
- apk update
- go build -o bin/hello
artifacts:
paths:
- bin/hello
expire_in: 1 week
deploy-job:
stage: deploy
script:
- echo "Deploying to Staging"
- scp bin/hello remoteuser@remotehost:/remote/directory
rules:
- if: $CI_COMMIT_BRANCH == 'staging'
artifacts:
paths:
- bin/hello
병렬
Jenkins에서 이전 작업에 의존하지 않는 작업은 parallel
섹션에 추가하면 병렬로 실행됩니다.
예를 들어, Jenkinsfile
에서:
pipeline {
agent any
stages {
stage('Parallel') {
parallel {
stage('Python') {
agent { docker 'python:latest' }
steps {
sh "python --version"
}
}
stage('Java') {
agent { docker 'openjdk:latest' }
when {
branch 'staging'
}
steps {
sh "java -version"
}
}
}
}
}
}
이 예제는 다른 컨테이너 이미지를 사용하여 Python 및 Java 작업을 병렬로 실행합니다. Java 작업은 staging
브랜치가 변경될 때에만 실행됩니다.
동등한 GitLab CI/CD .gitlab-ci.yml
파일은 다음과 같습니다:
python-version:
image: python:latest
script:
- python --version
java-version:
image: openjdk:latest
rules:
- if: $CI_COMMIT_BRANCH == 'staging'
script:
- java -version
이 경우 추가 구성이 필요하지 않습니다. 작업은 기본적으로 병렬로 실행되며, 모든 작업에 충분한 러너가 있다고 가정할 때, 각각의 작업은 다른 러너에서 실행됩니다. Java 작업은 staging
브랜치가 변경될 때만 실행되도록 설정되어 있습니다.
행렬
GitLab에서는 한 번의 파이프라인에서 동일한 작업을 여러 번 병렬로 실행하되 각 작업의 변수 값을 다르게 설정하여 행렬을 사용할 수 있지만, Jenkins는 행렬을 순차적으로 실행합니다.
예를 들어, Jenkinsfile
에서:
matrix {
axes {
axis {
name 'PLATFORM'
values 'linux', 'mac', 'windows'
}
axis {
name 'ARCH'
values 'x64', 'x86'
}
}
stages {
stage('build') {
echo "Building $PLATFORM for $ARCH"
}
stage('test') {
echo "Building $PLATFORM for $ARCH"
}
stage('deploy') {
echo "Building $PLATFORM for $ARCH"
}
}
}
동등한 GitLab CI/CD .gitlab-ci.yml
파일은 다음과 같습니다:
stages:
- build
- test
- deploy
.parallel-hidden-job:
parallel:
matrix:
- PLATFORM: [linux, mac, windows]
ARCH: [x64, x86]
build-job:
extends: .parallel-hidden-job
stage: build
script:
- echo "Building $PLATFORM for $ARCH"
test-job:
extends: .parallel-hidden-job
stage: test
script:
- echo "Testing $PLATFORM for $ARCH"
deploy-job:
extends: .parallel-hidden-job
stage: deploy
script:
- echo "Testing $PLATFORM for $ARCH"
컨테이너 이미지
GitLab에서는 독립된 격리된 Docker 컨테이너에서 CI/CD 작업을 실행하며, image 키워드를 사용합니다.
예를 들어, Jenkinsfile
에서:
stage('Version') {
agent { docker 'python:latest' }
steps {
echo 'Hello Python'
sh 'python --version'
}
}
이 예제는 python:latest
컨테이너에서 명령이 실행되는 것을 보여줍니다.
동등한 GitLab CI/CD .gitlab-ci.yml
파일은 다음과 같습니다:
version-job:
image: python:latest
script:
- echo "Hello Python"
- python --version
변수
GitLab에서는 CI/CD 변수를 정의하기 위해 variables
키워드를 사용합니다. 변수를 사용하여 구성 데이터를 재사용하거나 더 동적인 구성을 하거나 중요한 값을 저장할 수 있습니다. 변수는 전역적으로 또는 작업별로 정의할 수 있습니다.
예를 들어, Jenkinsfile
에서:
pipeline {
agent any
environment {
NAME = 'Fern'
}
stages {
stage('English') {
environment {
GREETING = 'Hello'
}
steps {
sh 'echo "$GREETING $NAME"'
}
}
stage('Spanish') {
environment {
GREETING = 'Hola'
}
steps {
sh 'echo "$GREETING $NAME"'
}
}
}
}
이 예제는 변수를 사용하여 작업에서 명령에 값을 전달하는 방법을 보여줍니다.
동등한 GitLab CI/CD .gitlab-ci.yml
파일은 다음과 같습니다:
default:
image: alpine:latest
stages:
- greet
variables:
NAME: "Fern"
english:
stage: greet
variables:
GREETING: "Hello"
script:
- echo "$GREETING $NAME"
spanish:
stage: greet
variables:
GREETING: "Hola"
script:
- echo "$GREETING $NAME"
또한 변수는 GitLab UI 또는 CI/CD 설정에서 설정할 수 있습니다. 일부 경우에는 비밀 값에 대한 보호된 및 마스킹된 변수를 사용할 수도 있습니다. 이러한 변수는 구성 파일에서 정의된 변수와 마찬가지로 파이프라인 작업에서 액세스할 수 있습니다.
예를 들어, Jenkinsfile
에서:
pipeline {
agent any
stages {
stage('Example Username/Password') {
environment {
AWS_ACCESS_KEY = credentials('aws-access-key')
}
steps {
sh 'my-login-script.sh $AWS_ACCESS_KEY'
}
}
}
}
동등한 GitLab CI/CD .gitlab-ci.yml
파일은 다음과 같습니다:
login-job:
script:
- my-login-script.sh $AWS_ACCESS_KEY
또한, GitLab CI/CD는 사전 정의된 변수를 모든 파이프라인 및 작업에 제공하여 파이프라인 및 리포지터리와 관련된 값을 포함하고 있습니다.
표현식과 조건문
새로운 파이프라인이 시작되면 GitLab은 해당 파이프라인에서 실행해야 할 작업을 확인합니다. 변수의 상태나 파이프라인 유형과 같은 요소에 따라 작업을 구성할 수 있습니다.
예를 들어, Jenkinsfile
에서:
stage('deploy_staging') {
agent { docker 'alpine:latest' }
when {
branch 'staging'
}
steps {
echo "Deploying to staging"
}
}
이 예제에서 작업은 커밋하는 브랜치가 staging
으로 명명된 경우에만 실행됩니다.
동등한 GitLab CI/CD .gitlab-ci.yml
파일은 다음과 같습니다:
deploy_staging:
stage: deploy
script:
- echo "Deploy to staging server"
rules:
- if: '$CI_COMMIT_BRANCH == staging'
러너
Jenkins 에이전트와 마찬가지로, GitLab 러너는 작업을 실행하는 호스트입니다. GitLab.com을 사용하는 경우, 자체 러너를 프로비저닝하지 않고 인스턴스 러너 플리트를 사용하여 작업을 실행할 수 있습니다.
Jenkins 에이전트와 유사한 프로비저닝을 사용하여 GitLab CI/CD에서 사용할 수 있습니다.
러너에 대한 몇 가지 주요 세부 정보는 다음과 같습니다:
- 러너는 인스턴스 전체, 그룹 또는 단일 프로젝트에 공유되거나 전용으로 구성될 수 있습니다.
- 태그 키워드를 사용하여 보다 정교하게 제어하고 특정 작업과 연관된 태그를 지정할 수 있습니다. 예를 들어 전용, 더 강력한 하드웨어 또는 특정 하드웨어에 대한 작업에 대한 태그를 사용할 수 있습니다.
- GitLab은 러너에 대한 자동 크기 조정을 제공합니다. 필요할 때만 러너를 프로비저닝하고 필요하지 않을 때는 스케일을 다운합니다.
예를 들어, Jenkinsfile
에서:
pipeline {
agent none
stages {
stage('Linux') {
agent {
label 'linux'
}
steps {
echo "Hello, $USER"
}
}
stage('Windows') {
agent {
label 'windows'
}
steps {
echo "Hello, %USERNAME%"
}
}
}
}
동등한 GitLab CI/CD .gitlab-ci.yml
파일은 다음과 같습니다:
linux_job:
stage: build
tags:
- linux
script:
- echo "Hello, $USER"
windows_job:
stage: build
tags:
- windows
script:
- echo "Hello, %USERNAME%"
아티팩트
GitLab에서는 작업이 완료될 때 저장될 아티팩트 집합을 정의하기 위해 artifacts
키워드를 사용할 수 있습니다. 아티팩트란 나중의 작업에서 사용할 수 있는 파일로, 예를 들어 테스트 또는 배포에 사용될 수 있습니다.
예를 들어 Jenkinsfile
에서:
stages {
stage('Generate Cat') {
steps {
sh 'touch cat.txt'
sh 'echo "meow" > cat.txt'
}
post {
always {
archiveArtifacts artifacts: 'cat.txt'
onlyIfSuccessful: true
}
}
}
stage('Use Cat') {
steps {
sh 'cat cat.txt'
}
}
}
동등한 GitLab CI/CD .gitlab-ci.yml
파일은 다음과 같을 것입니다:
stages:
- generate
- use
generate_cat:
stage: generate
script:
- touch cat.txt
- echo "meow" > cat.txt
artifacts:
paths:
- cat.txt
expire_in: 1 week
use_cat:
stage: use
script:
- cat cat.txt
artifacts:
paths:
- cat.txt
캐싱
작업이 한 개 이상의 파일을 다운로드하고 나중에 더 빠르게 액세스하기 위해 저장할 때 캐시가 생성됩니다. 동일한 캐시를 사용하는 후속 작업은 파일을 다시 다운로드할 필요가 없으므로 더 빠르게 실행됩니다. 캐시는 러너에 저장되며 분산 캐시가 활성화된 경우 S3에 업로드됩니다. Jenkins 코어는 캐싱을 제공하지 않습니다.
예를 들어, .gitlab-ci.yml
파일에서:
cache-job:
script:
- echo "This job uses a cache."
cache:
key: binaries-cache-$CI_COMMIT_REF_SLUG
paths:
- binaries/
Jenkins 플러그인
Jenkins에서 플러그인을 통해 활성화되는 일부 기능은 GitLab에서 유사한 기능을 제공하는 키워드와 기능으로 네이티브로 지원됩니다. 예를 들면:
보안 스캔 기능
Jenkins에서는 코드 품질, 보안 또는 정적 애플리케이션 스캐닝과 같은 것들에 대한 플러그인을 사용할 수 있습니다. GitLab은 SDLC의 모든 부분에서 취약점을 감지하기 위해 제공되는 보안 스캐너를 제공합니다. 예를 들어, 파이프라인에 SAST 스캔을 추가하려면 다음과 같이 .gitlab-ci.yml
에 추가할 수 있습니다:
include:
- template: Jobs/SAST.gitlab-ci.yml
또한 SAST 스캐너를 사용하여 보안 스캐너의 동작을 사용자 정의할 수 있습니다.
시크릿 관리
CI/CD 워크플로우에서 필요한 민감한 정보 또는 자격 증명인 “시크릿”은 보호된 리소스를 잠금 해제하거나 도구, 애플리케이션, 컨테이너 및 클라우드 네이티브 환경에서 민감한 정보를 사용하는 데 사용됩니다.
Jenkins에서의 시크릿 관리는 일반적으로 Secret
유형 필드나 자격 증명 플러그인을 통해 처리됩니다. Jenkins 설정에 저장된 자격 증명은 자격 증명 바인딩 플러그인을 사용하여 작업에서 환경 변수로 노출될 수 있습니다.
GitLab에서의 시크릿 관리는 외부 서비스에 대한 지원 통합 중 하나를 사용할 수 있습니다. 이러한 서비스는 GitLab 프로젝트 외부에 시크릿을 안전하게 저장하지만, 해당 서비스에 대한 구독이 있어야 합니다:
또한 GitLab은 OIDC를 지원하여 OIDC를 지원하는 기타 서드파티 서비스에 대해 OIDC 인증을 지원합니다.
또한 시크릿을 CI/CD 변수에 저장하여 작업에서 사용할 수 있도록 만들 수 있지만, 평문에 저장된 시크릿은 우연한 노출에 취약하며, Jenkins와 동일하게 일부 위험을 완화하는 masked 및 protected 변수에 민감한 정보를 항상 저장해야 합니다.
또한, 프로젝트의 .gitlab-ci.yml
파일에 시크릿을 변수로 저장해서는 안 되며, 이는 프로젝트에 액세스할 수 있는 모든 사용자에게 공개되기 때문입니다. 민감한 정보를 변수에 저장하는 것은 프로젝트, 그룹 또는 인스턴스 설정에서만 수행해야 합니다.
CI/CD 변수의 안전성을 향상시키기 위해 보안 지침을 검토해야 합니다.
마이그레이션 계획 수립 및 수행
다음 권장 사항 디렉터리은 이러한 마이그레이션을 신속하게 완료할 수 있는 조직들을 관찰한 후에 작성되었습니다.
마이그레이션 계획 작성
마이그레이션을 시작하기 전에 마이그레이션 계획을 작성하여 마이그레이션을 준비하기 위한 준비작업을 하여야 합니다. Jenkins에서의 마이그레이션을 위해서는 다음과 같은 질문을 스스로에게 물어보세요:
- Jenkins에서 사용 중인 작업에는 어떤 플러그인이 사용되나요?
- 이 플러그인이 정확히 무엇을 하는지 알고 있나요?
- 어떤 플러그인이 Maven, Gradle 또는 NPM과 같은 일반적인 빌드 도구를 랩핑하나요?
- Jenkins 에이전트에는 무엇이 설치되어 있나요?
- 공유 라이브러리가 사용 중인가요?
- Jenkins에서는 어떤 방법으로 인증하고 있나요? SSH 키, API 토큰 또는 기타 시크릿을 사용하고 있나요?
- 파이프라인에서 사용해야 하는 다른 프로젝트가 있나요?
- Jenkins에서 외부 서비스에 액세스하기 위한 자격증명이 있나요? 예를 들어 Ansible Tower, Artifactory 또는 기타 클라우드 제공 업체 또는 배포 대상이 있는가요?
전제조건
어떤 마이그레이션 작업을 수행하기 전에 먼저 다음을 해야합니다:
- GitLab을 숙지하세요.
- 중요한 GitLab CI/CD 기능을 참조하세요.
- 첫 번째 GitLab 파이프라인 및 더 복잡한 파이프라인이 포함된 튜토리얼을 따라보세요.
- CI/CD YAML 구문 참조를 검토하세요.
- GitLab을 설정하고 구성하세요.
- GitLab 인스턴스를 테스트하세요.
- 공유 GitLab.com 러너를 사용하거나 새 러너를 설치하여 러너(runner)가 사용 가능한지 확인하세요.
이주 단계
- 현재 SCM(Software Configuration Management) 솔루션에서 프로젝트를 GitLab으로 마이그레이션합니다.
- (권장) 외부 SCM 공급업체로부터 대량 가져오기를 자동화하기 위해 사용할 수 있는 가능한 importers를 사용할 수 있습니다.
- URL로 리포지터리 가져오기를 사용할 수 있습니다.
- 각 프로젝트에
.gitlab-ci.yml
파일을 생성합니다. - Jenkins 구성을 GitLab CI/CD 작업으로 마이그레이션하고 해당 결과를 Merge Request에서 직접 확인할 수 있도록 구성합니다.
- 클라우드 배포 템플릿, 환경, 그리고 Kubernetes를 위한 GitLab 에이전트를 사용하여 배포 작업을 마이그레이션합니다.
- 다른 프로젝트 간에 재사용할 수 있는 CI/CD 구성이 있는지 확인한 후, CI/CD 템플릿을 생성하고 공유합니다.
- GitLab CI/CD 파이프라인을 빠르고 효율적으로 만드는 방법을 알아보기 위해 파이프라인 효율성 문서를 확인하세요.
추가 자료
-
JenkinsFile Wrapper를 사용하여 플러그인을 포함한 완전한 Jenkins 인스턴스를 GitLab CI/CD 작업 내에서 실행할 수 있습니다. 이 도구를 사용하여 급하지 않은 파이프라인의 마이그레이션을 지연시켜 GitLab CI/CD로의 전환을 돕습니다.
JenkinsFile Wrapper는 GitLab과 함께 제공되지 않으며 지원 범위를 벗어납니다. 자세한 정보는 지원 성명서를 참조하십시오.
여기서 답변되지 않은 질문이 있다면 GitLab 커뮤니티 포럼이 좋은 자원이 될 수 있습니다.