- 키워드
- 전역 키워드
- 작업 키워드
- 사용되지 않는 키워드
CI/CD YAML 구문 참조
이 문서는 GitLab .gitlab-ci.yml
파일의 구성 옵션을 나열합니다.
이 파일은 파이프라인을 구성하는 CI/CD 작업을 정의하는 곳입니다.
-
기본 CI/CD 개념에 이미 익숙하다면 간단한 또는 복잡한 파이프라인을 보여주는 튜토리얼을 따라 직접
.gitlab-ci.yml
파일을 만들어 보세요. - 예제 모음은 GitLab CI/CD 예제를 참조하세요.
- 기업에서 사용 중인 큰
.gitlab-ci.yml
파일을 보려면 gitlab의.gitlab-ci.yml
파일을 확인하세요.
.gitlab-ci.yml
파일을 편집하는 경우 CI Lint 도구로 유효성을 검사할 수 있습니다.
이 페이지의 컨텐츠를 편집하는 경우 키워드 문서화 지침을 따르세요.
키워드
GitLab CI/CD 파이프라인 구성에는 다음이 포함됩니다.
-
키워드 설명 default
작업 키워드의 사용자 정의 기본 값. include
다른 YAML 파일에서 구성 가져오기. stages
파이프라인 스테이지의 이름과 순서. variables
파이프라인의 모든 작업에 대한 CI/CD 변수 정의. workflow
파이프라인 실행 유형을 제어. -
키워드 설명 spec
외부 구성 파일의 사양 정의. -
키워드 설명 after_script
작업 이후에 실행되는 명령어 세트 오버라이드. allow_failure
작업 실패를 허용. 실패한 작업은 파이프라인 실패를 일으키지 않음. artifacts
성공 시 작업에 첨부할 파일 및 디렉터리 목록. before_script
작업 이전에 실행되는 명령어 세트 오버라이드. cache
연속된 실행 사이에 캐시될 파일 목록. coverage
주어진 작업의 코드 커버리지 설정. dast_configuration
작업 수준의 DAST 프로필에서 구성 사용. dependencies
특정 작업으로 전달되는 아티팩트 제한. 아티팩트를 가져올 작업 목록 제공. environment
작업이 배포되는 환경의 이름. extends
이 작업이 상속하는 구성 항목. identity
신원 연합을 사용하여 타사 서비스와 인증. image
도커 이미지 사용. inherit
모든 작업이 상속하는 전역 기본값 선택. interruptible
더 최근 실행에 의해 불필요해 지면 작업을 취소할 수 있는지 여부 정의. needs
스테이지 순서 지정보다 이전에 작업 실행. pages
GitLab Pages에 사용할 작업 결과 업로드. parallel
작업을 병렬로 실행할 인스턴스 수. release
러너가 릴리스 오브젝트를 생성하도록 지시. resource_group
작업 동시성 제한. retry
작업이 실패한 경우 자동으로 재시도될 수 있는 시점 및 횟수 정의. rules
작업의 선택적 속성을 평가하고 결정하는 조건 목록 및 작성 여부. script
러너에서 실행되는 셸 스크립트. secrets
작업이 필요로 하는 CI/CD 비밀. services
도커 서비스 이미지 사용. stage
작업 스테이지 정의. tags
러너를 선택하는 데 사용되는 태그 목록. timeout
프로젝트 전역 설정보다 우선하는 사용자 정의 작업 수준 제한 시간 정의. trigger
하위 파이프라인 트리거 정의. variables
작업 수준에서 작업 변수 정의. when
작업 실행 시점.
전역 키워드
일부 키워드는 작업에서 정의되지 않습니다. 이러한 키워드는 파이프라인 동작을 제어하거나 추가적인 파이프라인 구성을 가져옵니다.
default
- GitLab 16.4에서 도입된
id_tokens
을 지원합니다.
몇 가지 키워드에 대한 전역 기본값을 설정할 수 있습니다. 각 기본 키워드는 이미 정의되지 않은 모든 작업에 복사됩니다. 작업에 이미 키워드가 정의되어 있는 경우 해당 기본값은 사용되지 않습니다.
키워드 유형: 전역 키워드.
가능한 입력값: 다음 키워드는 사용자 정의 기본값을 가질 수 있습니다:
after_script
artifacts
before_script
cache
hooks
id_tokens
image
interruptible
retry
services
tags
-
timeout
, 그러나 issue 213634로 인해 이 키워드는 효과가 없습니다.
default
의 예시:
default:
image: ruby:3.0
retry: 2
rspec:
script: bundle exec rspec
rspec 2.7:
image: ruby:2.7
script: bundle exec rspec
이 예시에서:
-
image: ruby:3.0
과retry: 2
는 파이프라인의 모든 작업에 대한 기본 키워드입니다. -
rspec
작업은image
또는retry
가 정의되지 않았으므로,image: ruby:3.0
및retry: 2
의 기본값을 사용합니다. -
rspec 2.7
작업은retry
가 정의되지 않았지만,image
가 명시적으로 정의되어 있습니다. 이는 기본retry: 2
를 사용하지만 기본image
는 무시하고 작업에서 정의된image: ruby:2.7
를 사용합니다.
추가 상세정보:
-
inherit:default
를 사용하여 작업에서 기본 키워드의 상속을 제어하세요.
include
- GitLab Free에서 11.4로 이동되었습니다.
include
를 사용하여 CI/CD 구성에서 외부 YAML 파일을 포함합니다.
하나의 긴 .gitlab-ci.yml
파일을 여러 파일로 분할하여 가독성을 높이거나, 동일한 구성의 중복을 줄일 수 있습니다.
템플릿 파일을 중앙 저장소에 저장하고 프로젝트에 포함할 수도 있습니다.
include
파일은:
-
.gitlab-ci.yml
파일에 있는 파일과 병합됩니다. - 항상 먼저 평가된 후에
.gitlab-ci.yml
파일의 내용과 병합됩니다.include
키워드의 위치에 관계없이 항상 먼저 평가된 후 .gitlab-ci.yml 파일의 내용과 병합됩니다.
모든 파일을 해결하는 시간 제한은 30초입니다.
키워드 유형: 전역 키워드.
가능한 입력값: include
하위 키:
그리고 선택적으로:
추가 상세정보:
-
include
키워드와 함께 특정 CI/CD 변수만 사용할 수 있습니다. - 병합을 사용하여 로컬 구성과 포함된 CI/CD 구성을 사용자 정의 및 재정의합니다.
-
.gitlab-ci.yml
파일에서 동일한 작업 이름 또는 전역 키워드를 사용하여 포함된 구성을 재정의할 수 있습니다. 두 구성은 병합되고, .gitlab-ci.yml 파일의 구성이 포함된 구성보다 우선합니다. - 작업을 다시 실행하면:
-
include
파일은 다시 가져오지 않습니다. 파이프라인의 모든 작업은 파이프라인이 생성될 때 가져온 구성을 사용합니다. 소스include
파일이 변경되어도 작업 다시 실행에는 영향을 미치지 않습니다. - 파이프라인을 다시 실행하면
include
파일이 다시 가져와집니다. 마지막 파이프라인 실행 이후 변경되었다면, 새 파이프라인은 변경된 구성을 사용합니다.
-
- 기본적으로 파이프라인 당 최대 150개의 include가 가능합니다. 추가로:
- GitLab 16.0 및 이후의 경우, 온프레미스 사용자는 최대 include 값을 변경할 수 있습니다.
- GitLab 15.10 및 이후에는 최대 150개의 include를 가질 수 있습니다. 중첩된 include의 경우 동일한 파일이 여러 번 포함될 수 있지만, 중복된 include는 제한에 포함됩니다.
- GitLab 14.9에서 GitLab 15.9까지 최대 100개의 include를 가질 수 있습니다. 중첩된 include의 경우 동일한 파일이 여러 번 포함될 수 있지만, 중복이 무시됩니다.
- GitLab 14.9 이전에는 최대 100개의 include를 가질 수 있지만, 동일한 파일을 여러 번 포함할 수 없습니다.
관련 주제:
include:component
include:component
를 사용하여 CI/CD 구성 요소를
파이프라인 구성에 추가합니다.
키워드 유형: 전역 키워드.
가능한 입력값: CI/CD 구성 요소의 전체 주소로, <fully-qualified-domain-name>/<project-path>/<component-name>@<specific-version>
형식으로 구성됩니다.
include:component
예시:
include:
- component: gitlab.example.com/my-org/security-components/secret-detection@1.0
관련 주제:
include:local
include:local
을 사용하여 구성 파일에 포함된 파일이 동일한 저장소 및 브랜치에 있는 파일을 포함합니다.
심볼릭 링크 대신 include:local
을 사용하세요.
키워드 유형: 전역 키워드.
가능한 입력값:
루트 디렉토리(/
)에 대한 전체 경로:
- YAML 파일은
.yml
또는.yaml
확장자를 가져야 합니다. - 파일 경로에 와일드카드(
*
및**
)를 사용할 수 있습니다. - 특정 CI/CD 변수를 사용할 수 있습니다.
include:local
예시:
include:
- local: '/templates/.gitlab-ci-template.yml'
경로를 정의하는 더 짧은 구문도 사용할 수 있습니다:
include: '.gitlab-ci-production.yml'
추가 세부 정보:
-
.gitlab-ci.yml
파일과 로컬 파일은 동일한 브랜치에 있어야 합니다. - Git 서브모듈 경로를 통해 로컬 파일을 포함할 수 없습니다.
- 모든 중첩된 포함은
include
키워드가 있는 구성 파일을 포함하는 프로젝트의 범위에서 실행됩니다. 로컬, 프로젝트, 원격, 또는 템플릿 포함을 사용할 수 있습니다.
include:project
- 같은 GitLab 인스턴스의 다른 비공개 프로젝트에서 여러 파일을 포함하는 기능은 GitLab 13.6에서 소개되었습니다. 기능 플래그가 GitLab 13.8에서 제거되었습니다.
동일한 GitLab 인스턴스의 다른 비공개 프로젝트에서 파일을 포함하려면
include:project
와 include:file
을 사용하세요.
키워드 유형: 전역 키워드.
가능한 입력값:
-
include:project
: 전체 GitLab 프로젝트 경로. -
include:file
: 루트 디렉토리(/
)에 상대적인 전체 파일 경로 또는 파일 경로 배열. YAML 파일은.yml
또는.yaml
확장자를 가져야 합니다. -
include:ref
: 선택 사항. 파일을 검색할 ref. 명시되지 않은 경우 기본값은 해당 프로젝트의HEAD
입니다. 특정 CI/CD 변수를 사용할 수 있습니다.
include:project
예시:
include:
- project: 'my-group/my-project'
file: '/templates/.gitlab-ci-template.yml'
- project: 'my-group/my-subgroup/my-project-2'
file:
- '/templates/.builds.yml'
- '/templates/.tests.yml'
ref
를 지정할 수도 있습니다:
include:
- project: 'my-group/my-project'
ref: main # Git 브랜치
file: '/templates/.gitlab-ci-template.yml'
- project: 'my-group/my-project'
ref: v1.0.0 # Git 태그
file: '/templates/.gitlab-ci-template.yml'
- project: 'my-group/my-project'
ref: 787123b47f14b552955ca2786bc9542ae66fee5b # Git SHA
file: '/templates/.gitlab-ci-template.yml'
추가 세부 정보:
- 모든 중첩된 포함은 중첩된
include
키워드가 있는 구성 파일을 포함하는 프로젝트의 범위에서 실행됩니다. 로컬(include
키워드가 있는 구성 파일을 포함하는 프로젝트에 상대적), 프로젝트, 원격, 또는 템플릿 포함을 사용할 수 있습니다. - 파이프라인이 시작되면 모든 방법으로 포함된
.gitlab-ci.yml
파일 구성이 평가됩니다. 구성은 시간에 따른 스냅샷이며 데이터베이스에 유지됩니다. GitLab은 참조된.gitlab-ci.yml
파일 구성의 변경을 다음 파이프라인이 시작될 때까지 반영하지 않습니다. - 다른 비공개 프로젝트에서 YAML 파일을 포함할 때, 파이프라인을 실행하는 사용자는 두 프로젝트의 멤버이어야 하고 파이프라인을 실행할 적절한 권한을 가져야 합니다.
포함된 파일 중 어느 것에 대한 액세스 권한이 없는 경우
not found or access denied
오류가 표시될 수 있습니다. - 다른 프로젝트의 CI/CD 구성 파일을 포함할 때 주의하세요. CI/CD 구성 파일이 변경될 때 파이프라인이나 알림이 트리거되지 않습니다.
보안 측면에서, 이는 제3자 종속성을 가져오는 것과 유사합니다.
ref
의 경우 다음을 고려하세요:
include:remote
다른 위치의 파일을 포함하려면 전체 URL과 함께 include:remote
를 사용하세요.
키워드 유형: 전역 키워드.
가능한 입력:
HTTP/HTTPS GET
요청으로 접근 가능한 공개 URL:
- 원격 URL로의 인증은 지원되지 않습니다.
- YAML 파일의 확장자는
.yml
또는.yaml
이어야 합니다. - 특정 CI/CD 변수를 사용할 수 있습니다.
include:remote
의 예시:
include:
- remote: 'https://gitlab.com/example-project/-/raw/main/.gitlab-ci.yml'
추가 정보:
- 모든 중첩된 포함은 공개 사용자로서 컨텍스트 없이 실행되므로, 공개 프로젝트 또는 템플릿만 포함할 수 있습니다. 중첩된 포함의
include
섹션에서 변수를 사용할 수 없습니다. - 다른 프로젝트의 CI/CD 구성 파일을 포함할 때 주의하십시오. 다른 프로젝트 파일이 변경되면 파이프라인이 실행되거나 알림이 트리거되지 않습니다. 보안적인 측면에서 이는 써드파티 종속성을 끌어들이는 것과 유사합니다. 소유한 다른 GitLab 프로젝트에 링크하는 경우, 보호된 브랜치와 보호된 태그의 사용을 고려하여 변경 관리 규칙을 시행하세요.
include:template
.gitlab-ci.yml
템플릿을 포함하기 위해 include:template
를 사용하세요.
키워드 유형: 전역 키워드.
가능한 입력:
- 모든 템플릿은
lib/gitlab/ci/templates
에서 볼 수 있습니다.include:template
와 함께 사용하기 위해 설계된 템플릿은 모두가 아니므로 사용하기 전에 템플릿 설명을 확인하세요. - 특정 CI/CD 변수를 사용할 수 있습니다.
include:template
의 예시:
# GitLab 템플릿 컬렉션에서 가져온 파일
include:
- template: Auto-DevOps.gitlab-ci.yml
여러 include:template
파일:
include:
- template: Android-Fastlane.gitlab-ci.yml
- template: Auto-DevOps.gitlab-ci.yml
추가 정보:
- 모든 중첩된 포함은 공개 사용자로서 컨텍스트 없이 실행되므로, 공개 프로젝트 또는 템플릿만 포함할 수 있습니다. 중첩된 포함의
include
섹션에서 변수를 사용할 수 없습니다.
include:inputs
- Beta 기능으로 도입됨 GitLab 15.11.
include:inputs
를 사용하여 포함된 구성이 spec:inputs
를 사용하고 파이프라인에 추가될 때 입력 매개변수의 값을 설정하세요.
키워드 유형: 전역 키워드.
가능한 입력: 문자열, 숫자 값 또는 부울.
include:inputs
의 예시:
include:
- local: 'custom_configuration.yml'
inputs:
website: "My website"
이 예시에서:
-
custom_configuration.yml
에 포함된 구성은website
입력을My website
값으로 설정하여 파이프라인에 추가됩니다.
추가 정보:
- 포함된 구성 파일이
spec:inputs:type
을 사용하는 경우, 입력 값은 정의된 유형과 일치해야 합니다. - 포함된 구성 파일이
spec:inputs:options
을 사용하는 경우, 입력 값은 나열된 옵션 중 하나와 일치해야 합니다.
관련 주제:
-
include
사용 시 입력 값을 설정하는 방법에 대해 알아보세요(inputs.md#set-input-values-when-using-include).
stages
- 중첩된 문자열 배열 지원 도입됨 GitLab 16.9.
stages
를 사용하여 작업 그룹을 포함하는 단계를 정의하세요. 작업을 특정 단계에서 실행하도록 구성하려면 작업에서 stage
를 사용하세요.
만약 .gitlab-ci.yml
파일에 stages
가 정의되어 있지 않다면, 기본 파이프라인 단계는 다음과 같습니다:
stages
의 항목 순서는 작업의 실행 순서를 정의합니다:
- 같은 단계 내의 작업은 병렬로 실행됩니다.
- 다음 단계의 작업은 이전 단계의 작업이 성공적으로 완료된 후에 실행됩니다.
파이프라인에 .pre
, .post
단계에 속한 작업만 있는 경우 파이프라인은 실행되지 않습니다. 다른 단계에 적어도 하나의 작업이 있어야 합니다. .pre
및 .post
단계는 필수 파이프라인 구성에서 프로젝트 파이프라인 작업보다 먼저 또는 후에 실행되어야 하는 규정 준수 작업을 정의하는 데 사용할 수 있습니다.
키워드 유형: 전역 키워드.
stages
의 예시:
stages:
- build
- test
- deploy
이 예시에서:
-
build
의 모든 작업이 병렬로 실행됩니다. -
build
의 모든 작업이 성공하면test
의 작업이 병렬로 실행됩니다. -
test
의 모든 작업이 성공하면deploy
의 작업이 병렬로 실행됩니다. -
deploy
의 모든 작업이 성공하면 파이프라인이passed
로 표시됩니다.
만약 작업 중 하나라도 실패하면 파이프라인이 failed
로 표시되고, 이후 단계의 작업은 시작되지 않습니다. 현재 단계의 작업은 중지되지 않고 계속 실행됩니다.
추가 정보:
- 만약 작업이
stage
를 지정하지 않은 경우, 해당 작업은test
단계에 할당됩니다. - 단계가 정의되었지만 작업에서 사용하지 않는다면, 해당 단계는 파이프라인에서 보이지 않습니다. 이는 규정 준수 파이프라인 구성을 도와줍니다:
- 단계는 규정 준수 구성에서 정의되지만 작업에서 사용되지 않으면 표시되지 않습니다.
- 개발자가 작업 정의에서 사용할 때만 정의된 단계가 표시됩니다.
워크플로우
- GitLab 12.5에서 도입됨
워크플로우
를 사용하여 파이프라인 동작을 제어합니다.
워크플로우
구성에서 사전 정의된 CI/CD 변수를 사용할 수 있지만, 작업이 시작될 때만 정의된 변수는 사용할 수 없습니다.
관련 주제:
워크플로우: 규칙
예제- 브랜치 파이프라인과 병합 요청 파이프라인 간 전환 (workflow.md#switch-between-branch-pipelines-and-merge-request-pipelines)
워크플로우:auto_cancel:on_new_commit
- 기본 설정으로 비활성화된 상태로 GitLab 16.8에서 도입됨.
- GitLab 16.9에서 GitLab.com 및 자체 관리형 환경에서 활성화됨.
- GitLab 16.10에서 일반 사용 가능함. 기능 플래그
ci_workflow_auto_cancel_on_new_commit
가 제거됨.
워크플로우:auto_cancel:on_new_commit
을 사용하여 자동으로 취소되는 중복 파이프라인 기능의 동작을 구성합니다.
가능한 입력:
-
보수적
: 파이프라인을 취소하지만interruptible: false
작업이 시작되지 않은 경우에만 취소됨. 정의되지 않은 경우 기본값. -
interruptible
:interruptible: true
인 작업만 취소함. -
없음
: 어떠한 작업도 자동으로 취소하지 않음.
workflow:auto_cancel:on_new_commit
예시:
workflow:
auto_cancel:
on_new_commit: interruptible
job1:
interruptible: true
script: sleep 60
job2:
interruptible: false # 정의되지 않았을 때의 기본값.
script: sleep 60
이 예시에서:
- 브랜치에 새로운 커밋이 푸시되면 GitLab은 새로운 파이프라인을 생성하고
job1
및job2
가 시작됩니다. - 작업이 완료되기 전에 브랜치에 새로운 커밋이 푸시되면
job1
만 취소됩니다.
워크플로우:auto_cancel:on_job_failure
- 기본 설정으로 비활성화된 상태로 GitLab 16.10에서 도입됨.
auto_cancel_pipeline_on_job_failure
이름의 기능 플래그를 활성화할 수 있습니다.
GitLab.com 및 GitLab Dedicated에서는 이 기능을 사용할 수 없습니다.워크플로우:auto_cancel:on_job_failure
을 사용하여 한 작업이 실패하자마자 취소할 작업을 구성합니다.
가능한 입력:
-
모두
: 한 작업이 실패하자마자 파이프라인과 모든 실행 중인 작업을 취소함. -
없음
: 어떠한 작업도 자동으로 취소하지 않음.
workflow:auto_cancel:on_job_failure
예시:
stages: [stage_a, stage_b]
workflow:
auto_cancel:
on_job_failure: all
job1:
stage: stage_a
script: sleep 60
job2:
stage: stage_a
script:
- sleep 30
- exit 1
job3:
stage: stage_b
script:
- sleep 30
이 예시에서 job2
가 실패하면, 실행 중인 job1
이 아직 실행 중이고 job3
이 시작되지 않은 경우 job1
이 취소됩니다.
관련 주제:
워크플로우:name
- 기본 설정으로 비활성화된 상태로 GitLab 15.5에서 도입됨.
- GitLab 15.7에서 GitLab.com 및 자체 관리형 환경에서 활성화됨.
- GitLab 15.8에서 일반 사용 가능함. 기능 플래그
pipeline_name
이 제거됨.
workflow:
에서 name
을 사용하여 파이프라인에 이름을 정의할 수 있습니다.
모든 파이프라인에 정의된 이름이 할당됩니다. 이름에 있는 선행 또는 후행 공백은 제거됩니다.
가능한 입력:
- 문자열.
- CI/CD 변수.
- 두 가지의 조합.
workflow:name
예시:
사전 정의된 변수를 사용한 간단한 파이프라인 이름:
workflow:
name: '브랜치용 파이프라인: $CI_COMMIT_BRANCH'
파이프라인 조건에 따라 다른 파이프라인 이름이 있는 구성:
variables:
PROJECT1_PIPELINE_NAME: '기본 파이프라인 이름' # 기본값은 필요하지 않음.
workflow:
name: '$PROJECT1_PIPELINE_NAME'
rules:
- if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
variables:
PROJECT1_PIPELINE_NAME: 'MR 파이프라인: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME'
- if: '$CI_MERGE_REQUEST_LABELS =~ /pipeline:run-in-ruby3/'
variables:
PROJECT1_PIPELINE_NAME: '루비 3 파이프라인'
- when: always # 다른 파이프라인은 실행되지만 기본 이름을 사용함
추가 정보:
- 이름이 빈 문자열인 경우 파이프라인에 이름이 할당되지 않습니다. 모든 변수도 빈 문자열인 경우 이름도 빈 문자열로 평가될 수 있습니다.
-
workflow:rules:variables
는 전역 변수로 설정되어 모든 작업에서 사용할 수 있으며, 변수를 기본적으로 하위 파이프라인으로 전달하는trigger
작업을 포함합니다. 하위 파이프라인에서 동일한 변수를 사용하는 경우, 상위 변수 값에 의해 변수가 덮어씌워집니다. 아래 중 하나를 반드시 지켜야 합니다:- 모든 프로젝트의 파이프라인 구성에서 고유한 변수 이름을 사용하십시오. (예:
PROJECT1_PIPELINE_NAME
) - inherit:variables를 트리거 작업에서 사용하고 전달할 변수를 명시적으로 나열하십시오.
- 모든 프로젝트의 파이프라인 구성에서 고유한 변수 이름을 사용하십시오. (예:
workflow:rules
workflow
내부의 rules
키워드는 작업에서 정의된 rules
과 유사하지만,
파이프라인 전체가 생성되는지를 제어합니다.
어떤 규칙도 true로 평가되지 않으면 파이프라인은 실행되지 않습니다.
가능한 입력값: 작업 수준의 rules
와 동일한 키워드를 사용할 수 있습니다:
-
rules: if
. -
rules: changes
. -
rules: exists
. -
when
,workflow
와 함께 사용될 때always
또는never
만 가능합니다. -
variables
.
workflow:rules
예시:
workflow:
rules:
- if: $CI_COMMIT_TITLE =~ /-draft$/
when: never
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
이 예시에서는 커밋 제목(커밋 메시지의 첫 번째 줄)이 -draft
로 끝나지 않고,
파이프라인이 다음 중 하나인 경우에 실행됩니다:
- 병합 요청
- 기본 브랜치
추가 정보:
- 브랜치 파이프라인(기본 브랜치를 제외한 다른 브랜치)과 병합 요청 파이프라인이 모두 규칙과 일치하는 경우, 중복 파이프라인이 발생할 수 있습니다.
관련 주제:
-
workflow:rules
템플릿을 사용하여 미리 구성된workflow: rules
항목을 가져올 수 있습니다. -
workflow:rules
에 대한 일반적인if
절. -
병합 요청 파이프라인 실행에
rules
사용.
workflow:rules:variables
- GitLab 13.11에서 소개됨.
- GitLab 14.1에서 기능 플래그가 제거됨.
workflow:rules
에서 variables
를 사용하여
특정 파이프라인 조건에 대한 변수를 정의할 수 있습니다.
조건이 일치하는 경우에 변수가 생성되며, 파이프라인의 모든 작업에서 사용할 수 있습니다.
전역 레벨에서 이미 정의된 변수가 있는 경우 workflow
변수가 우선시되어 전역 변수를 재정의합니다.
키워드 유형: 전역 키워드.
가능한 입력값: 변수 이름 및 값 쌍:
- 이름은 숫자, 문자 및 밑줄(
_
) 만 사용할 수 있습니다. - 값은 문자열이어야 합니다.
workflow:rules:variables
예시:
variables:
DEPLOY_VARIABLE: "default-deploy"
workflow:
rules:
- if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
variables:
DEPLOY_VARIABLE: "deploy-production" # 전역으로 정의된 DEPLOY_VARIABLE 재정의
- if: $CI_COMMIT_REF_NAME =~ /feature/
variables:
IS_A_FEATURE: "true" # 새 변수 정의.
- when: always # 다른 경우에 파이프라인 실행
job1:
variables:
DEPLOY_VARIABLE: "job1-default-deploy"
rules:
- if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
variables: # 정의된 DEPLOY_VARIABLE 재정의
DEPLOY_VARIABLE: "job1-deploy-production" # 작업 수준에서.
- when: on_success # 다른 경우에 작업 실행
script:
- echo "Run script with $DEPLOY_VARIABLE as an argument"
- echo "Run another script if $IS_A_FEATURE exists"
job2:
script:
- echo "Run script with $DEPLOY_VARIABLE as an argument"
- echo "Run another script if $IS_A_FEATURE exists"
기본 브랜치일 때:
- job1의
DEPLOY_VARIABLE
은job1-deploy-production
입니다. - job2의
DEPLOY_VARIABLE
은deploy-production
입니다.
feature
브랜치일 때:
- job1의
DEPLOY_VARIABLE
은job1-default-deploy
이고,IS_A_FEATURE
은true
입니다. - job2의
DEPLOY_VARIABLE
은default-deploy
이고,IS_A_FEATURE
은true
입니다.
다른 브랜치일 때:
- job1의
DEPLOY_VARIABLE
은job1-default-deploy
입니다. - job2의
DEPLOY_VARIABLE
은default-deploy
입니다.
추가 정보:
-
workflow:rules:variables
는 모든 작업, 기본적으로 하위 파이프라인으로 변수를 전달하는trigger
작업을 포함한 모든 작업에서 사용할 수 있는 전역 변수가 됩니다. 하위 파이프라인에서 동일한 변수를 사용하는 경우, 상위 변수 값에 의해 변수가 덮어씌워집니다. 모든 프로젝트의 파이프라인 구성에서는 고유한 변수 이름을 사용하거나,- 트리거 작업에서
inherit:variables
를 사용하고 하위 파이프라인으로 전달하려는 정확한 변수를 나열합니다.
- 트리거 작업에서
workflow:rules:auto_cancel
- GitLab 16.8에 [게시됨](https://gitlab.com/gitlab-org/gitlab/-/issues/436467)으로
ci_workflow_auto_cancel_on_new_commit
이라는 플래그로 도입되었습니다. 기본으로 비활성화됩니다. - GitLab 16.9에서 GitLab.com 및 Self-Managed에서 [활성화됩니다](https://gitlab.com/gitlab-org/gitlab/-/issues/434676).
- GitLab 16.10에서 [일반적으로 사용 가능합니다](https://gitlab.com/gitlab-org/gitlab/-/issues/434676).
ci_workflow_auto_cancel_on_new_commit
플래그가 제거되었습니다.
workflow:rules:auto_cancel
을 사용하여 workflow:auto_cancel:on_new_commit
기능을 구성합니다.
가능한 입력:
-
on_new_commit
:workflow:auto_cancel:on_new_commit
workflow:rules:auto_cancel
예시:
workflow:
auto_cancel:
on_new_commit: interruptible
rules:
- if: $CI_COMMIT_REF_PROTECTED == 'true'
auto_cancel:
on_new_commit: none
- when: always # 다른 경우에는 파이프라인 실행
test-job1:
script: sleep 10
interruptible: false
test-job2:
script: sleep 10
interruptible: true
이 예시에서는 기본적으로 모든 작업에 대해 workflow:auto_cancel:on_new_commit
이 interruptible
로 설정되어 있습니다. 그러나 파이프라인이 보호된 브랜치에서 실행되면 규칙이 기본 값을 on_new_commit: none
으로 덮어씁니다. 예를 들어, 보호되지 않은 브랜치에서 새 커밋이 푸시된 경우, test-job1
은 계속 실행되고 test-job2
는 취소됩니다. 보호된 브랜치에서 새 커밋이 푸시된 경우 test-job1
및 test-job2
모두 계속 실행됩니다.
## 헤더 키워드
일부 키워드는 YAML 구성 파일의 헤더 섹션에 정의해야 합니다. 헤더는 파일의 맨 위에 있어야 하며, ---
로 나머지 구성과 구분되어야 합니다.
spec
spec
섹션을 추가하여 include
키워드를 사용하여 파이프라인에 추가된 구성을 구성하는 데 사용합니다.
spec:inputs
spec:inputs
를 사용하여 include
로 파이프라인에 추가할 CI/CD 구성의 입력 매개변수를 정의할 수 있습니다. include
로 실행될 때 사용할 값을 정의하기 위해 include:inputs
를 사용하십시오.
입력을 사용하여 CI/CD 구성이 파이프라인에 추가될 때의 동작을 사용자 정의하세요.
해석 형식 $[[ input.input-id ]]
을 사용하여 헤더 섹션 외부의 값에 참조합니다. 입력은 구성이 파이프라인 생성 중에 가져올 때, .gitlab-ci.yml
파일의 내용과 병합되기 전에 평가 및 보간됩니다.
키워드 유형: 헤더 키워드입니다. specs
는 설정 파일의 맨 위에 선언되어야 합니다.
가능한 입력: 예상되는 입력을 나타내는 문자열의 해시입니다.
spec:inputs
예시:
spec:
inputs:
environment:
job-stage:
---
scan-website:
stage: $[[ inputs.job-stage ]]
script: ./scan-website $[[ inputs.environment ]]
추가 세부 정보:
-
specs
에서spec:inputs:default
를 사용하여 기본값을 설정하지 않는 한, 입력은 필수입니다. - 입력은 다른 입력 유형을 설정하기 위해
spec:inputs:type
을 사용하지 않는 한 문자열을 기대합니다. - 보간 블록 내의 문자열은 1MB를 초과해서는 안 됩니다.
- 보간 블록 내의 문자열은 1KB를 초과해서는 안 됩니다.
관련 주제:
spec:inputs:default
include
로 포함될 때 입력은 기본적으로 필수입니다. 그러나 spec:inputs:default
로 기본값을 설정해두면 예외적입니다.
default: ''
를 사용하여 기본값이 없도록 할 수 있습니다.
키워드 유형: 헤더 키워드입니다. specs
는 설정 파일의 맨 위에 선언되어야 합니다.
가능한 입력: 기본값을 나타내는 문자열 또는 ''
.
spec:inputs:default
예시:
spec:
inputs:
website:
user:
default: 'test-user'
flags:
default: ''
---
# 파이프라인 구성이 이어집니다...
이 예에서:
-
website
는 필수이며 정의되어야 합니다. -
user
는 선택 사항입니다. 정의되지 않은 경우 값은test-user
입니다. -
flags
는 선택 사항입니다. 정의되지 않으면 값이 없습니다.
추가 세부 정보:
- 입력이 다음 중 하나일 때 유효성 오류로 파이프라인이 실패합니다:
spec:inputs:description
- GitLab 16.5에서 도입되었습니다.
description
를 사용하여 특정 입력에 설명을 제공합니다. 설명은 입력의 동작에 영향을 주지 않으며 파일의 사용자가 입력을 이해하는 데 도움이 되도록 사용됩니다.
키워드 유형: 헤더 키워드. specs
는 구성 파일의 맨 위에 선언되어야 합니다.
헤더 섹션내에서만 사용됩니다.
가능한 입력값: 입력 설명을 나타내는 문자열입니다.
spec:inputs:description
의 예시:
spec:
inputs:
flags:
description: 'flags` 입력 상세에 대한 샘플 설명입니다.'
---
# 파이프라인 구성이 이어집니다...
spec:inputs:options
- GitLab 16.6에서 도입되었습니다.
입력은 options
를 사용하여 입력에 대한 허용된 값 목록을 지정할 수 있습니다. 입력당 50개의 옵션으로 제한됩니다.
키워드 유형: 헤더 키워드. specs
는 구성 파일의 맨 위에 선언되어야 합니다.
헤더 섹션내에서만 사용됩니다.
가능한 입력값: 입력 옵션의 배열입니다.
spec:inputs:options
의 예시:
spec:
inputs:
environment:
options:
- development
- staging
- production
---
# 파이프라인 구성이 이어집니다...
이 예시에서:
-
environment
은 필수이며 목록 중 하나의 값으로 정의되어야 합니다.
추가 정보:
- 입력이
options
와default
을 모두 사용하고 기본값이 목록된 옵션 중 하나가 아닌 경우, 또는 입력 옵션 중 어느 하나가type
과 일치하지 않을 때 파이프라인은 유효성 검사 오류로 실패합니다. 이는options
를 사용할 때type
이string
또는number
여야 하고,boolean
은 사용할 수 없는 것입니다.
spec:inputs:regex
- GitLab 16.5에서 도입되었습니다.
spec:inputs:regex
를 사용하여 입력이 일치해야 하는 정규 표현식을 지정합니다.
키워드 유형: 헤더 키워드. specs
는 구성 파일의 맨 위에 선언되어야 합니다.
헤더 섹션내에서만 사용됩니다.
가능한 입력값: 반드시 /
문자로 시작하고 끝나는 정규 표현식이어야 합니다.
spec:inputs:regex
의 예시:
spec:
inputs:
version:
regex: /^v\d\.\d+(\.\d+)$/
---
# 파이프라인 구성이 이어집니다...
이 예시에서 v1.0
또는 v1.2.3
의 입력은 정규 표현식과 일치하여 유효성을 통과합니다.
하지만 v1.A.B
의 입력은 정규 표현식과 일치하지 않아 유효성 검사를 통과하지 못합니다.
추가 정보:
-
inputs:regex
은type
이number
또는boolean
이 아닌string
과만 함께 사용될 수 있습니다.
spec:inputs:type
기본적으로 입력은 문자열을 기대합니다. 입력에 대해 다른 필수 유형을 설정하려면 spec:inputs:type
를 사용합니다.
키워드 유형: 헤더 키워드. specs
는 구성 파일의 맨 위에 선언되어야 합니다.
헤더 섹션내에서만 사용됩니다.
가능한 입력값: 다음 중 하나일 수 있습니다:
-
string
: 문자열 입력을 허용합니다 (정의되지 않으면 기본값). -
number
: 숫자 입력만 허용합니다. -
boolean
:true
또는false
입력만 허용합니다.
spec:inputs:type
의 예시:
spec:
inputs:
job_name:
website:
type: string
port:
type: number
available:
type: boolean
---
# 파이프라인 구성이 이어집니다...
작업 키워드
다음 주제에서는 CI/CD 파이프라인을 구성하는 데 사용하는 키워드를 설명합니다.
after_script
after_script
를 사용하여 작업의 script
섹션 이후에 실행되는 명령의 배열을 정의합니다. 이는 script_failure
실패 유형이 있는 실패 작업도 포함합니다.
after_script
명령은 다른 실패 유형 후에는 실행되지 않습니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.
또는 default
섹션에서 사용할 수 있습니다.
가능한 입력값: 아래를 포함하는 배열:
CI/CD 변수 지원됨.
after_script
의 예시:
job:
script:
- echo "예시 스크립트 섹션입니다."
after_script:
- echo "`script` 섹션이 완료된 후에 이 명령을 실행하세요."
추가 정보:
after_script
에 지정한 스크립트는 before_script
또는 script
명령에서 수행한 변경사항과 독립된 새 쉘에서 실행됩니다. 결과적으로 다음과 같은 특징을 가지게 됩니다:
- 현재 작업 디렉터리는 기본값으로 설정됩니다 (런너가 Git 요청을 처리하는 방식을 정의하는 변수에 따라).
-
before_script
또는script
스크립트에서 수행한 변경사항의 접근 권한이 없습니다.-
script
스크립트에서 내보낸 명령 별칭 및 변수. -
before_script
또는script
스크립트에서 설치한 소프트웨어와 같은 작업 영역 외의 변경사항 (런너 실행자에 따라 달라집니다).
-
- 별도의 타임아웃이 적용됩니다. GitLab Runner 16.4 및 이후에는 기본값이 5분이며,
RUNNER_AFTER_SCRIPT_TIMEOUT
변수로 구성할 수 있습니다. GitLab 16.3 및 이전 버전에서는 타임아웃이 하드코딩되어 5분으로 설정됩니다. - 작업의 종료 코드에 영향을 주지 않습니다.
script
섹션이 성공하고after_script
명령이 타임아웃되거나 실패하더라도 작업은 코드0
(작업 성공
)으로 종료됩니다.
작업이 시간 초과되거나 취소된 경우 after_script
명령은 실행되지 않습니다.
타임아웃된 또는 취소된 작업에 after_script
명령을 실행하도록 지원하기 위한 이슈가 있습니다.
관련 주제:
-
default
와 함께after_script
사용 모든 작업 이후에 실행할 기본 명령어 배열을 정의합니다. - 0이 아닌 종료 코드 무시.
-
after_script
와 함께 색 코드 사용 작업 로그를 검토하기 쉽게 만듭니다. - 사용자 정의 축소 가능한 섹션 만들기 작업 로그 출력을 단순화합니다.
allow_failure
allow_failure
을 사용하여 작업이 실패한 경우에도 파이프라인을 계속 실행할지 여부를 결정합니다.
- 후속 작업을 계속 실행하려면
allow_failure: true
를 사용하세요. - 후속 작업을 실행하지 않으려면
allow_failure: false
를 사용하세요.
작업이 실패해도(allow_failure: true
) 오렌지색 경고()가 표시되며, 이는 작업이 실패했음을 나타냅니다. 그러나 파이프라인은 성공하며 관련 커밋은 경고 없이 통과된 것으로 표시됩니다.
이와 유사한 경고가 다음 경우에도 표시됩니다.
- 단계 내의 다른 모든 작업이 성공한 경우.
- 파이프라인 내의 다른 모든 작업이 성공한 경우.
allow_failure
의 기본값은 다음과 같습니다.
-
수동 작업의 경우
true
입니다. -
rules
내부에서when: manual
을 사용하는 작업의 경우false
입니다. - 그 외의 모든 경우에는
false
입니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.
가능한 입력값:
-
true
또는false
.
allow_failure
의 예시:
job1:
stage: test
script:
- execute_script_1
job2:
stage: test
script:
- execute_script_2
allow_failure: true
job3:
stage: deploy
script:
- deploy_to_staging
environment: staging
이 예시에서 job1
과 job2
는 병렬로 실행됩니다.
-
job1
이 실패하면deploy
단계의 작업이 시작되지 않습니다. -
job2
가 실패해도deploy
단계의 작업은 계속해서 시작될 수 있습니다.
추가 정보:
-
allow_failure
을rules
의 하위 키로 사용할 수 있습니다. -
allow_failure: true
가 설정된 경우, 해당 작업은 항상 성공으로 간주되고, 이 작업이 실패하는 경우 나중에when: on_failure
을 가진 작업이 시작되지 않습니다. - 수동 작업에
allow_failure: false
를 사용하여 차단 수동 작업을 만들 수 있습니다. 차단된 파이프라인은 수동 작업이 시작되고 성공적으로 완료될 때까지 나중 단계의 작업을 실행하지 않습니다.
allow_failure:exit_codes
allow_failure:exit_codes
를 사용하여 작업이 언제 실패해도 되는지를 제어합니다. 작업은 목록된 종료 코드 중 어느 것이든 allow_failure: true
이며, 다른 종료 코드의 경우 allow_failure
는 false입니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.
가능한 입력값:
- 단일 종료 코드.
- 종료 코드의 배열.
allow_failure
의 예시:
test_job_1:
script:
- echo "종료 코드 1로 이어지는 스크립트 실행. 이 작업은 실패합니다."
- exit 1
allow_failure:
exit_codes: 137
test_job_2:
script:
- echo "종료 코드 137로 이어지는 스크립트 실행. 이 작업은 실패해도 됩니다."
- exit 137
allow_failure:
exit_codes:
- 137
- 255
artifacts
artifacts
를 사용하여 작업 아티팩트로 저장할 파일을 지정합니다. 작업 아티팩트는 작업이 성공, 실패 또는 항상 경우에 해당하는 파일 및 디렉토리 목록입니다.
작업이 완료된 후 아티팩트는 GitLab으로 전송됩니다. 파일 크기가 최대 아티팩트 크기보다 작은 경우 GitLab UI에서 다운로드할 수 있습니다.
기본적으로, 나중 단계의 작업은 앞 단계의 작업에서 생성된 모든 아티팩트를 자동으로 다운로드합니다. dependencies
를 사용하여 작업에서 아티팩트 다운로드 동작을 제어할 수 있습니다.
needs
키워드를 사용할 때 작업은 needs
구성에서 정의된 작업에서만 아티팩트를 다운로드할 수 있습니다.
작업 아티팩트는 기본적으로 성공한 작업에 대해서만 수집되며, 캐시 이후에 아티팩트가 복원됩니다.
아티팩트에 대한 추가 정보를 읽어보세요.
artifacts:paths
경로는 프로젝트 디렉토리($CI_PROJECT_DIR
)를 기준으로 하며 직접 외부에 링크될 수 없습니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.
가능한 입력값:
- 프로젝트 디렉토리를 기준으로 한 파일 경로의 배열.
-
글롭 패턴을 사용하는 와일드카드:
-
GitLab Runner 13.0 이상에서
doublestar.Glob
. - GitLab Runner 12.10 이하에서
filepath.Match
.
-
GitLab Runner 13.0 이상에서
CI/CD 변수는 지원됩니다.
artifacts:paths
의 예시:
job:
artifacts:
paths:
- binaries/
- .config
이 예시에서 .config
와 binaries
디렉토리의 모든 파일을 포함하여 아티팩트가 생성됩니다.
추가 정보:
-
artifacts:name
과 함께 사용하지 않으면, 아티팩트 파일의 이름은artifacts
로 지정되며, 다운로드 시artifacts.zip
가 됩니다.
관련 주제:
- 특정 작업이 어떤 작업에서 아티팩트를 가져올지 제한하려면
dependencies
를 참조하세요. - 작업 아티팩트 생성.
artifacts:exclude
- GitLab 13.1에서 소개됨
- GitLab Runner 13.1이 필요합니다.
artifacts:exclude
를 사용하여 파일이 아티팩트 아카이브에 추가되지 않도록 합니다.
Keyword type: Job keyword. job의 일부로만 사용하거나 default
section에서만 사용할 수 있습니다.
가능한 입력:
- 프로젝트 디렉토리를 기준으로 한 파일 경로의 배열.
-
glob 또는
doublestar.PathMatch
패턴을 사용하는 와일드카드.
artifacts:exclude
의 예시:
artifacts:
paths:
- binaries/
exclude:
- binaries/**/*.o
이 예시는 binaries/
의 모든 파일을 저장하지만, binaries/
의 하위 디렉터리에 있는 *.o
파일은 저장하지 않습니다.
추가 세부 정보:
-
artifacts:exclude
경로는 재귀적으로 검색되지 않습니다. -
artifacts:untracked
에 의해 일치하는 파일도artifacts:exclude
를 사용하여 제외할 수 있습니다.
관련 주제:
artifacts:expire_in
- 비활성화된 기능 플래그 뒤에서 사용 가능했던 GitLab 13.0에서 도입됨으로써 가장 최근의 작업 아티팩트는 만료 시간에 관계없이 유지됩니다.
- GitLab 13.4에서 기본 동작으로 설정됨.
- GitLab 13.8에서 프로젝트 수준에서 최신 작업 아티팩트를 비활성화할 수 있음.
- GitLab 13.9에서 인스턴스 전역에서 최신 작업 아티팩트를 비활성화할 수 있음.
expire_in
을 사용하여 작업 아티팩트가 만료되어 삭제되기 전에 저장되는 기간을 지정합니다. expire_in
설정은 다음에 영향을 주지 않습니다:
- 최신 작업 아티팩트는 유지됩니다. 최신 작업 아티팩트를 프로젝트 수준에서 비활성화하지 않는 한 가장 최근의 성공한 작업에서 아티팩트 유지 및 인스턴스 전역에서 모든 작업의 최신 성공 파이프라인에서 최신 아티팩트 유지에 영향을 주지 않습니다.
만료된 후, 아티팩트는 기본적으로 시간당 삭제되며(크론 작업 사용), 더 이상 접근할 수 없습니다.
Keyword type: Job keyword. job의 일부로만 사용하거나 default
section에서만 사용할 수 있습니다.
가능한 입력: 만료 시간. 단위가 제공되지 않으면 시간은 초 단위입니다. 유효한 값은 다음과 같습니다:
'42'
42 seconds
3 mins 4 sec
2 hrs 20 min
2h20min
6 mos 1 day
47 yrs 6 mos and 4d
3 weeks and 2 days
never
artifacts:expire_in
의 예시:
job:
artifacts:
expire_in: 1 week
추가 세부 정보:
- 만료 시간은 아티팩트가 GitLab에 업로드되고 저장된 시점부터 시작됩니다. 만료 시간이 정의되지 않으면 기본적으로 인스턴스 전역 설정으로 설정됩니다.
- 만료 날짜를 재정의하고 아티팩트가 자동으로 삭제되는 것을 방지하려면:
- 작업 페이지에서 유지를 선택하세요.
- GitLab 13.3 이상에서
expire_in
의 값 설정을never
로 설정하십시오.
- 작업 페이지에서 유지를 선택하세요.
- GitLab 13.3 이상에서
- 만료 시간이 너무 짧으면 장시간 파이프라인의 나중 작업에서 만료된 아티팩트를 검색하려고 시도할 수 있습니다.
만약 아티팩트가 만료되면, 그것들을 가져 오려고 하는 작업이
필요한 아티팩트를 검색할 수 없음
오류과 함께 실패합니다. 만료 시간을 더 길게 설정하거나 나중 작업에서dependencies
를 사용하여 다음에는 만료된 아티팩트를 가져 오지 않도록하십시오.
artifacts:expose_as
artifacts:expose_as
키워드를 사용하여 병합 요청 UI에서 작업 아티팩트 노출합니다.
Keyword type: Job keyword. job의 일부로만 사용하거나 default
section에서만 사용할 수 있습니다.
가능한 입력:
- 병합 요청 UI에서 아티팩트 다운로드 링크에 표시할 이름.
반드시
artifacts:paths
와 함께 사용해야 합니다.
artifacts:expose_as
의 예시:
test:
script: ["echo 'test' > file.txt"]
artifacts:
expose_as: 'artifact 1'
paths: ['file.txt']
추가 세부 정보:
- 아티팩트는 저장되지만, 만약
artifacts:paths
값이:- CI/CD 변수를 사용.
- 디렉터리를 정의하지만
/
로 끝나지 않는 경우. 예를 들어,directory/
는artifacts:expose_as
와 함께 작동하지만,directory
는 작동하지 않습니다. -
./
로 시작됩니다. 예를 들어,file
는artifacts:expose_as
와 함께 작동하지만,./file
는 작동하지 않습니다.
- 병합 요청당 최대 10개의 작업 아티팩트를 노출할 수 있습니다.
- Glob 패턴은 지원되지 않습니다.
- 디렉터리가 지정되고 해당 디렉터리에 파일이 하나 이상 있는 경우, 링크는 작업 아티팩트 브라우저로 이동합니다.
-
GitLab Pages가 활성화되어 있는 경우,
GitLab은 단일 파일 아티팩트를 자동으로 렌더링합니다. 다음과 같은 확장자를 가진 파일의 경우:
-
.html
또는.htm
.txt
.json
.xml
.log
-
관련 주제:
artifacts:name
artifacts:name
키워드를 사용하여 생성된 artifact 아카이브의 이름을 정의합니다. 각 아카이브에 고유한 이름을 지정할 수 있습니다.
정의되지 않을 경우, 기본 이름은 artifacts
이며, 이는 다운로드시 artifacts.zip
이 됩니다.
키워드 타입: 작업 키워드. 작업의 일부로만 사용하거나 default
섹션에서만 사용할 수 있습니다.
가능한 입력:
- Artifact 아카이브의 이름. CI/CD 변수 지원됨.
artifacts:paths
와 결합되어야 함.
artifacts:name
의 예시:
현재 작업의 이름으로 아카이브를 생성하려면:
job:
artifacts:
name: "job1-artifacts-file"
paths:
- binaries/
관련 주제:
artifacts:public
artifacts:public
을 사용하여 작업 artifact를 공개적으로 사용 가능한지 여부를 결정합니다.
artifacts:public
이 true
(기본값)로 설정되어있을 때, 공개 파이프라인의 artifact는 익명, 게스트, 그리고 기고자 사용자에 의해 다운로드할 수 있습니다.
익명, 게스트, 그리고 기고자 사용자를 위해 공개 파이프라인의 아티팩트에 대한 읽기 액세스를 거부하려면 artifacts:public
을 false
로 설정하세요:
키워드 타입: 작업 키워드. 작업의 일부로만 사용하거나 default
섹션에서만 사용할 수 있습니다.
가능한 입력:
-
true
(정의되지 않은 경우 기본값) 또는false
.
artifacts:public
의 예시:
job:
artifacts:
public: false
artifacts:reports
템플릿에서 생성된 아티팩트를 수집하려면 artifacts:reports
를 사용하세요.
키워드 타입: 작업 키워드. 작업의 일부로만 사용하거나 default
섹션에서만 사용할 수 있습니다.
가능한 입력:
- 사용 가능한 아티팩트 보고서 유형 목록 참조.
artifacts:reports
의 예시:
rspec:
stage: test
script:
- bundle install
- rspec --format RspecJunitFormatter --out rspec.xml
artifacts:
reports:
junit: rspec.xml
추가 정보:
- 부모 파이프라인에서 자식 파이프라인으로부터 아티팩트를 결합하는 것은 지원되지 않습니다. 이에 대한 지원 추가 진행 상황은 이 이슈에서 추적하십시오.
- 보고서 출력 파일을 둘러볼 수 있도록 하려면
artifacts:paths
키워드를 포함시키세요. 이렇게 하면 아티팩트가 두 번 업로드되고 저장됩니다. -
artifacts: reports
로 생성된 아티팩트는 작업 결과(성공 또는 실패)에 관계없이 항상 업로드됩니다. 아티팩트의 유효 기간을 설정하려면artifacts:expire_in
을 사용하세요.
artifacts:untracked
artifacts:untracked
를 사용하여 Git의 추적되지 않은 파일을 모두 artifact로 추가합니다 (artifacts:paths
에 정의된 경로와 함께). artifacts:untracked
은 저장소의 .gitignore
구성을 무시하므로 .gitignore
에서 매칭되는 아티팩트가 포함됩니다.
키워드 타입: 작업 키워드. 작업의 일부로만 사용하거나 default
섹션에서만 사용할 수 있습니다.
가능한 입력:
-
true
또는false
(정의되지 않은 경우 기본값).
artifacts:untracked
의 예시:
모든 Git 추적되지 않은 파일 저장:
job:
artifacts:
untracked: true
관련 주제:
artifacts:when
artifacts:when
을 사용하여 작업 실패 시 또는 실패에 상관없이 아티팩트를 업로드하세요.
키워드 타입: 작업 키워드. 작업의 일부로만 사용하거나 default
섹션에서만 사용할 수 있습니다.
가능한 입력:
-
on_success
(기본값): 작업이 성공했을 때만 아티팩트를 업로드합니다. -
on_failure
: 작업이 실패했을 때만 아티팩트를 업로드합니다. -
always
: 항상 아티팩트를 업로드합니다 (작업 시간이 초과된 경우를 제외). 예를 들어, 실패하는 테스트를 해결하기 위해 업로드되는 아티팩트가 필요한 경우.
artifacts:when
의 예시:
job:
artifacts:
when: on_failure
추가 정보:
-
artifacts:reports
용으로 생성된 아티팩트는 작업 결과(성공 또는 실패)에 상관없이 항상 업로드됩니다.artifacts:when
은 이 동작을 변경하지 않습니다.
before_script
before_script
을 사용하여 각 작업의 script
명령어보다는 실행되지만, artifacts가 복원된 후에 실행되어야 하는 명령어 배열을 정의합니다.
키워드 유형: Job 키워드. 작업의 일부로만 사용하거나 default
section에서만 사용할 수 있습니다.
가능한 입력: 다음을 포함하는 배열:
- Single line commands.
- 여러 줄에 걸쳐 분할된 긴 명령어.
- YAML 앵커.
CI/CD 변수 지원됨.
before_script
예시:
job:
before_script:
- echo "스크립트 명령어 이전에 이 명령어를 실행합니다."
script:
- echo "이 명령어는 작업의 'before_script' 명령어 후에 실행됩니다."
추가 정보:
-
before_script
에서 지정한 스크립트는 주요script
에서 지정한 스크립트와 연결되어 단일 셸에서 함께 실행됩니다. - 최상위 수준의
before_script
을 사용하되default
section에는 사용하지 말아야 합니다. 폐기됨.
관련 주제:
- [default
와 함께
before_script사용](script.md#set-a-default-before_script-or-after_script-for-all-jobs)하여 모든 작업의
script` 명령어 전에 실행되어야 하는 기본 명령어 배열을 정의합니다. - 0이 아닌 종료 코드 무시.
- before_script`에 색상 코드 사용하여 작업 로그를 쉽게 검토할 수 있습니다.
- 사용자 지정 접기 가능한 섹션 만들기하여 작업 로그 출력을 단순화합니다.
cache
- GitLab 15.0에서 도입되었으며 캐시는 보호된 브랜치와 비보호된 브랜치 간에 공유되지 않습니다.
cache
를 사용하여 작업 간에 캐시해야 할 파일과 디렉토리 목록을 지정합니다. 로컬 작업 복사본에 있는 경로만 사용할 수 있습니다.
캐시는 다음과 같습니다:
특정 작업에 대해 캐싱을 비활성화할 수 있습니다. 예를 들어:
캐시에 대한 자세한 정보는 GitLab CI/CD에서 캐싱을 참조하십시오.
cache:paths
cache:paths
키워드를 사용하여 캐시할 파일 또는 디렉토리를 선택합니다.
키워드 유형: Job 키워드. 작업의 일부로만 사용하거나 default
section에서만 사용할 수 있습니다.
가능한 입력:
- 프로젝트 디렉토리(
$CI_PROJECT_DIR
)를 기준으로 하는 경로 배열입니다. glob 패턴을 사용하는 와일드카드를 사용할 수 있습니다:-
GitLab Runner 13.0 and later에서는
doublestar.Glob
. - GitLab Runner 12.10 이전에서는
filepath.Match
.
-
GitLab Runner 13.0 and later에서는
cache:paths
예시:
.apk
로 끝나는 binaries
의 모든 파일과 .config
파일을 캐시:
rspec:
script:
- echo "이 작업은 캐시를 사용합니다."
cache:
key: binaries-cache
paths:
- binaries/*.apk
- .config
추가 정보:
-
cache:paths
키워드를 사용하면.gitignore
파일에 포함되지 않거나 추적되지 않아도 파일이 포함됩니다.
관련 주제:
- 더 많은 캐시 패스 예시를 보려면 일반적인
cache
사용 사례를 참조하세요.
cache:key
cache:key
키워드를 사용하여 각 캐시에 고유한 식별 키를 지정합니다. 동일한 캐시 키를 사용하는 모든 작업은 다른 파이프라인을 포함하여 동일한 캐시를 사용합니다.
설정되지 않은 경우 기본 키는 default
입니다. cache
키워드가지만 cache:key
가 없는 모든 작업은 default
캐시를 공유합니다.
cache: paths
와 함께 사용해야 하며, 그렇지 않으면 캐시되지 않습니다.
키워드 유형: Job 키워드. 작업의 일부로만 사용하거나 default
section에서만 사용할 수 있습니다.
가능한 입력:
- 문자열.
- 미리 정의된 CI/CD 변수.
- 둘 다의 조합.
cache:key
예시:
cache-job:
script:
- echo "이 작업은 캐시를 사용합니다."
cache:
key: binaries-cache-$CI_COMMIT_REF_SLUG
paths:
- binaries/
추가 정보:
-
Windows Batch를 사용하여 셸 스크립트를 실행하는 경우
$
를%
로 바꿔야 합니다. 예:key: %CI_COMMIT_REF_SLUG%
-
cache:key
값은 다음을 포함할 수 없습니다.-
/
문자 또는 동등한 URI 인코딩%2F
. -
.
문자(어떤 수의), 또는 동등한 URI 인코딩%2E
.
-
- 캐시는 작업 간에 공유되므로 다른 작업에 대해 다른 경로를 사용하는 경우 다른
cache:key
를 설정해야 합니다. 그렇지 않으면 캐시 내용이 덮어씌워질 수 있습니다.
관련 주제:
- 지정된
cache:key
를 찾을 수 없는 경우 대체 캐시 키를 지정할 수 있습니다. - 단일 작업에서 여러 캐시 키를 사용할 수 있습니다.
- 더 많은 캐시 키 예시를 보려면 일반적인
cache
사용 사례를 참조하세요.
cache:key:files
- GitLab 12.5에서 소개되었습니다.
cache:key:files
키워드를 사용하여 하나 또는 두 개의 특정 파일이 변경될 때 새 키를 생성합니다. cache:key:files
를 사용하면 일부 캐시를 재사용하고 덜 자주 다시 만들어서 후속 파이프라인 실행 속도를 높일 수 있습니다.
키워드 타입: 작업 키워드. 작업의 일부로만 또는 default
섹션에서만 사용할 수 있습니다.
가능한 입력:
- 하나 또는 두 파일 경로의 배열.
CI/CD 변수는 지원되지 않습니다.
cache:key:files
의 예시:
cache-job:
script:
- echo "This job uses a cache."
cache:
key:
files:
- Gemfile.lock
- package.json
paths:
- vendor/ruby
- node_modules
이 예시에서는 Ruby 및 Node.js 종속성에 대한 캐시를 생성합니다. 이 캐시는 Gemfile.lock
및 package.json
파일의 현재 버전에 연결됩니다. 이 파일 중 하나가 변경되면 새 캐시 키가 계산되고 새로운 캐시가 생성됩니다. cache:key:files
와 함께 동일한 Gemfile.lock
및 package.json
을 사용하는 미래 작업 실행은 종속성을 다시 빌드하는 대신 새 캐시를 사용합니다.
추가 세부정보:
- 캐시
key
는 나열된 각 파일을 변경한 가장 최근의 커밋에서 계산된 SHA입니다. 어떤 커밋에서도 파일이 변경되지 않으면 대체 키는default
입니다.
cache:key:prefix
- GitLab 12.5에서 소개되었습니다.
cache:key:prefix
를 사용하여 cache:key:files
에 대한 SHA와 접두사를 결합합니다.
키워드 타입: 작업 키워드. 작업의 일부로만 또는 default
섹션에서만 사용할 수 있습니다.
가능한 입력:
- 문자열
- 사전 정의된 변수
- 둘 다의 조합.
cache:key:prefix
의 예시:
rspec:
script:
- echo "This rspec job uses a cache."
cache:
key:
files:
- Gemfile.lock
prefix: $CI_JOB_NAME
paths:
- vendor/ruby
예를 들어, prefix
로 $CI_JOB_NAME
을 추가하면 키는 rspec-feef9576d21ee9b6a32e30c5c79d0a0ceb68d1e5
와 같을 것입니다. Gemfile.lock
을 변경하면 해당 브랜치에 대해 cache:key:files
의 새로운 SHA 체크섬이 생깁니다. 새로운 캐시 키가 생성되고 해당 키에 대한 새로운 캐시가 만들어집니다. Gemfile.lock
를 찾을 수 없으면 접두사가 default
에 추가되므로 위 예시의 키는 rspec-default
가 됩니다.
추가 세부정보:
-
cache:key:files
의 어떤 파일도 어떤 커밋에서 변경되지 않으면 접두사가default
키에 추가됩니다.
cache:untracked
untracked: true
를 사용하여 Git 저장소에서 추적되지 않는 모든 파일을 캐시합니다. 추적되지 않는 파일에는 다음이 포함됩니다:
-
.gitignore
구성으로 인해 무시되는 파일. -
git add
로 체크아웃에 추가되지 않은 파일.
추적되지 않는 파일을 캐시하면 작업이 다음을 다운로드할 때 예상치 못한 큰 캐시를 생성할 수 있습니다:
- 보통 추적되지 않는 종속성, 예를 들어 젬이나 노드 모듈.
- 다른 작업에서 가져온 아티팩트. 아티팩트에서 추출한 파일은 기본적으로 추적되지 않습니다.
키워드 타입: 작업 키워드. 작업의 일부로만 또는 default
섹션에서만 사용할 수 있습니다.
가능한 입력:
-
true
또는false
(기본).
cache:untracked
의 예시:
rspec:
script: test
cache:
untracked: true
추가 세부정보:
-
cache:untracked
를cache:paths
와 결합하여 저장소의 모든 추적되지 않는 파일뿐만 아니라 구성된 경로에 있는 모든 파일도 캐시할 수 있습니다. 추적된 파일 뿐만 아니라 작업 디렉토리 외부에 있는 파일이나 특정 파일을 모두 캐시하려면cache:paths
를 사용하고, 추적되지 않는 파일도 모두 캐시하려면cache:untracked
를 사용하세요. 예를 들어:rspec: script: test cache: untracked: true paths: - binaries/
이 예시에서는 작업이 저장소의 모든 추적되지 않는 파일과
binaries/
에 있는 모든 파일을 캐시합니다.binaries/
에 추적되지 않는 파일이 있는 경우 두 키워드 모두에 해당됩니다.
cache:unprotect
- 소개됨 in GitLab 15.8.
cache:unprotect
를 사용하여 보호된 브랜치와 비보호된 브랜치 간에 공유되는 캐시를 설정합니다.
경고:
true
로 설정하면 보호된 브랜치에 액세스 권한이 없는 사용자도 보호된 브랜치에서 사용하는 캐시 키를 읽거나 쓸 수 있습니다.
키워드 유형: Job 키워드. Job의 일부로만 사용하거나 default
섹션에서만 사용할 수 있습니다.
가능한 입력값:
-
true
또는false
(기본값).
cache:unprotect
의 예시:
rspec:
script: test
cache:
unprotect: true
cache:when
- 소개됨 in GitLab 13.5 and GitLab Runner v13.5.0.
cache:when
을 사용하여 작업의 상태에 따라 캐시를 저장할 시기를 정의합니다.
cache: paths
와 함께 사용해야 하며, 아무것도 캐시되지 않습니다.
키워드 유형: Job 키워드. Job의 일부로만 사용하거나 default
섹션에서만 사용할 수 있습니다.
가능한 입력값:
-
on_success
(기본값): 작업이 성공했을 때에만 캐시를 저장합니다. -
on_failure
: 작업이 실패했을 때에만 캐시를 저장합니다. -
always
: 항상 캐시를 저장합니다.
cache:when
의 예시:
rspec:
script: rspec
cache:
paths:
- rspec/
when: 'always'
이 예시는 작업이 성공하거나 실패하더라도 캐시를 저장합니다.
cache:policy
캐시의 업로드 및 다운로드 동작을 변경하려면 cache:policy
키워드를 사용합니다.
기본적으로, 작업은 시작할 때 캐시를 다운로드하고, 종료할 때 변경 사항을 업로드합니다. 이 캐싱 스타일은 pull-push
정책(기본값)입니다.
작업을 시작할 때에만 캐시를 다운로드하고, 종료할 때 변경 사항을 업로드하지 않도록 설정하려면 cache:policy:pull
을 사용합니다.
작업을 종료할 때에만 캐시를 업로드하고, 시작할 때 캐시를 다운로드하지 않도록 설정하려면 cache:policy:push
을 사용합니다.
cache: paths
와 함께 사용해야 하며, 아무것도 캐시되지 않습니다.
키워드 유형: Job 키워드. Job의 일부로만 사용하거나 default
섹션에서만 사용할 수 있습니다.
가능한 입력값:
pull
push
-
pull-push
(기본값) - CI/CD 변수.
cache:policy
의 예시:
prepare-dependencies-job:
stage: build
cache:
key: gems
paths:
- vendor/bundle
policy: push
script:
- echo "This job only downloads dependencies and builds the cache."
- echo "Downloading dependencies..."
faster-test-job:
stage: test
cache:
key: gems
paths:
- vendor/bundle
policy: pull
script:
- echo "This job script uses the cache, but does not update it."
- echo "Running tests..."
관련 주제:
cache:fallback_keys
cache:fallback_keys
를 사용하여 cache:key
에 대한 캐시가 없는 경우 캐시를 복원하기 위해 시도할 키 목록을 지정합니다. 캐시는 fallback_keys
섹션에 지정된 순서대로 검색됩니다.
키워드 유형: Job 키워드. Job의 일부로만 사용하거나 default
섹션에서만 사용할 수 있습니다.
가능한 입력값:
- 캐시 키의 배열
cache:fallback_keys
의 예시:
rspec:
script: rspec
cache:
key: gems-$CI_COMMIT_REF_SLUG
paths:
- rspec/
fallback_keys:
- gems
when: 'always'
coverage
coverage
를 사용하여 작업 출력에서 코드 커버리지를 추출하는 데 사용할 사용자 정의 정규 표현식을 구성합니다. 적어도 일부 행이 정규 표현식과 일치하는 경우 UI에 커버리지가 표시됩니다.
가능한 입력값:
- RE2 정규 표현식.
/
로 시작하고 끝나야 합니다. 커버리지 번호와 일치해야 합니다. 주변 텍스트도 일치할 수 있으므로 정확한 번호를 캡처하기 위해 정규 표현식 문자 그룹을 사용할 필요가 없습니다. RE2 구문을 사용하기 때문에 모든 그룹은 캡처되지 않아야 합니다.
coverage
의 예시:
job1:
script: rspec
coverage: '/Code coverage: \d+(?:\.\d+)?/'
이 예시에서:
- GitLab은 작업 로그에서 정규 표현식과 일치하는 항목을 찾습니다.
Code coverage: 67.89% of lines covered
와 같이 한 줄이 일치할 수 있습니다. - 그런 다음 GitLab은 일치하는 조각에서
\d+(?:\.\d+)?
에 일치하는지 확인합니다. 위의 샘플 일치 항목은 코드 커버리지를67.89
로 제공합니다.
추가 정보:
- 코드 커버리지에서 구문 분석 예시를 찾을 수 있습니다.
- 작업 출력에 여러 일치 항목이 있는 경우 마지막 줄이 사용됩니다 (역방향 검색의 첫 번째 결과).
- 일치하는 조각에서 여러 일치 항목이 있는 경우 첫 번째 숫자가 사용됩니다.
- 선행 0은 제거됩니다.
- 하위 파이프라인의 커버리지 출력은 기록되거나 표시되지 않습니다. 자세한 내용은 관련 이슈를 확인하세요.
dast_configuration
세부정보: Tier: Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated
- GitLab 14.1에서 소개되었습니다.
dast_configuration
키워드를 사용하여 CI/CD 구성에서 사용될 사이트 프로필 및 스캐너 프로필을 지정합니다. 두 프로필 모두 먼저 프로젝트에 생성되어야 합니다. 작업의 단계는 반드시 dast
여야 합니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.
가능한 입력값: site_profile
및 scanner_profile
의 각각 하나씩.
-
site_profile
은 작업에서 사용할 사이트 프로필을 지정합니다. -
scanner_profile
은 작업에서 사용할 스캐너 프로필을 지정합니다.
dast_configuration
의 예:
stages:
- build
- dast
include:
- template: DAST.gitlab-ci.yml
dast:
dast_configuration:
site_profile: "Example Co"
scanner_profile: "Quick Passive Test"
이 예에서 dast
작업은 include
키워드로 추가된 dast
구성을 확장하여 특정 사이트 프로필 및 스캐너 프로필을 선택합니다.
추가 세부정보:
- 사이트 프로필 또는 스캐너 프로필에 포함된 설정은 DAST 템플릿에 포함된 설정보다 우선합니다.
관련 주제:
dependencies
dependencies
키워드를 사용하여 artifacts를 가져올 특정 작업의 목록을 정의합니다. 지정된 작업은 모두 이전 단계에 있어야 합니다. 또한 작업을 전혀 가져오지 않도록 설정할 수도 있습니다.
작업에서 dependencies
가 정의되지 않은 경우 이전 단계의 모든 작업이 종속 작업으로 간주되며 작업은 이러한 작업에서 모든 artifacts를 가져옵니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.
가능한 입력값:
- Artifacts를 가져올 작업의 이름.
- 빈 배열(
[]
), 작업에서 어떤 artifacts도 다운로드하지 않도록 구성합니다.
dependencies
의 예:
build osx:
stage: build
script: make build:osx
artifacts:
paths:
- binaries/
build linux:
stage: build
script: make build:linux
artifacts:
paths:
- binaries/
test osx:
stage: test
script: make test:osx
dependencies:
- build osx
test linux:
stage: test
script: make test:linux
dependencies:
- build linux
deploy:
stage: deploy
script: make deploy
environment: production
이 예에서 build osx
및 build linux
두 작업에는 artifacts가 있습니다. test osx
가 실행될 때 build osx
의 artifacts가 다운로드되어 빌드의 컨텍스트에서 추출됩니다. test linux
의 경우도 마찬가지로 build linux
의 artifacts가 동일하게 처리됩니다.
단계 우선순위 때문에 deploy
작업은 모든 이전 작업에서 artifacts를 가져옵니다.
추가 세부정보:
- 작업의 상태는 중요하지 않습니다. 작업이 실패하거나 수동으로 트리거되지 않은 경우에도 오류가 발생하지 않습니다.
- 종속 작업의 artifacts가 만료되거나 삭제된 경우 작업이 실패합니다.
- 동일 단계의 작업에서 artifacts를 가져오려면
needs:artifacts
를 사용해야 합니다. 작업에서dependencies
와needs
를 동시에 결합해서는 안 됩니다.
environment
environment
를 사용하여 작업이 배포되는 환경을 정의합니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.
가능한 입력값: 작업이 배포되는 환경의 이름으로 다음 형식 중 하나:
-
-
,_
,/
,$
,{
,}
와 같은 문자를 포함하는 영문자, 숫자, 공백을 포함하는 일반 텍스트. -
.gitlab-ci.yml
파일에서 정의된 CI/CD 변수또는 프리디파인, 프로젝트, 그룹, 인스턴스 변수.script
섹션에서 정의된 변수는 사용할 수 없습니다.
environment
의 예:
deploy to production:
stage: deploy
script: git push production HEAD:main
environment: production
추가 세부정보:
- 지정된
environment
가 존재하지 않는 경우, 환경은 생성됩니다.
environment:name
환경에 이름을 설정합니다.
일반적인 환경 이름은 qa
, staging
, production
입니다. 그러나 임의의 이름을 사용할 수 있습니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.
가능한 입력값: 작업이 배포되는 환경의 이름으로 다음 형식 중 하나:
-
-
,_
,/
,$
,{
,}
와 같은 문자를 포함하는 영문자, 숫자, 공백을 포함하는 일반 텍스트. -
CI/CD 변수또는
.gitlab-ci.yml
파일에서 정의된 프리디파인, 프로젝트, 그룹, 인스턴스 변수.script
섹션에서 정의된 변수는 사용할 수 없습니다.
environment:name
의 예:
deploy to production:
stage: deploy
script: git push production HEAD:main
environment:
name: production
environment:url
환경에 대한 URL을 설정합니다.
키워드 유형: Job 키워드. Job의 일부로만 사용할 수 있습니다.
가능한 입력값: 다음 중 하나의 형식으로 된 URL
-
https://prod.example.com
과 같은 일반 텍스트 -
CI/CD 변수로, 미리 정의된 변수, 프로젝트, 그룹, 인스턴스 또는
.gitlab-ci.yml
파일에서 정의된 변수를 포함합니다.script
섹션에서 정의된 변수는 사용할 수 없습니다.
environment:url
의 예시:
production으로 배포:
stage: deploy
script: git push production HEAD:main
environment:
name: production
url: https://prod.example.com
추가 세부 정보:
- Job이 완료된 후 URL에 액세스하려면, 병합 요청, 환경 또는 배포 페이지에서 버튼을 선택할 수 있습니다.
environment:on_stop
on_stop
키워드를 사용하여 환경을 닫는 작업(job)을 정의하여 환경의 종료(중단)를 달성할 수 있습니다. 이는 environment
아래에 정의된 다른 작업(job)을 선언합니다.
키워드 유형: Job 키워드. Job의 일부로만 사용할 수 있습니다.
추가 세부 정보:
- 자세한 내용 및 예시는
environment:action
을 참조하세요.
environment:action
Job이 환경과 상호 작용하는 방법을 지정하기 위해 action
키워드를 사용합니다.
키워드 유형: Job 키워드. Job의 일부로만 사용할 수 있습니다.
가능한 입력값: 다음 중 하나의 키워드
값 | 설명 |
---|---|
start
| 기본값. Job이 환경을 시작시킵니다. Job이 시작된 후 배포가 생성됩니다. |
prepare
| Job이 환경을 준비하는 것만을 나타냅니다. 배포를 트리거하지 않습니다. 환경 준비에 대한 자세한 내용을 참조하세요. |
stop
| Job이 환경을 중단시킵니다. 환경 중단에 대한 자세한 내용을 참조하세요. |
verify
| Job이 환경을 확인하는 것만을 나타냅니다. 배포를 트리거하지 않습니다. 환경 확인에 대한 자세한 내용을 참조하세요. |
access
| Job이 환경에 액세스하는 것만을 나타냅니다. 배포를 트리거하지 않습니다. 환경 액세스에 대한 자세한 내용을 참조하세요. |
environment:action
의 예시:
review 앱 중단:
stage: deploy
variables:
GIT_STRATEGY: none
script: make delete-app
when: manual
environment:
name: review/$CI_COMMIT_REF_SLUG
action: stop
environment:auto_stop_in
- GitLab 15.4에서 도입된 CI/CD 변수를 지원합니다.
auto_stop_in
키워드는 환경의 수명을 지정합니다. 환경이 만료되면 GitLab에서 자동으로 중지합니다.
키워드 유형: Job 키워드. Job의 일부로만 사용할 수 있습니다.
가능한 입력값: 자연어로 작성된 시간의 기간. 예를 들어, 다음과 같습니다:
168시간
7일
한 주
never
CI/CD 변수는 지원됩니다.
environment:auto_stop_in
의 예시:
review 앱:
script: deploy-review-app
environment:
name: review/$CI_COMMIT_REF_SLUG
auto_stop_in: 1일
review 앱
에 대한 환경이 생성되면, 환경의 수명이 1일
로 설정됩니다. 매번 리뷰 앱이 배포될 때마다 해당 수명도 1일
로 재설정됩니다.
관련 주제:
environment:kubernetes
- GitLab 12.6에서 도입된 기능입니다.
kubernetes
키워드를 사용하여 프로젝트와 관련된 Kubernetes 클러스터에 대한 배포를 구성합니다.
키워드 유형: Job 키워드. Job의 일부로만 사용할 수 있습니다.
environment:kubernetes
의 예시:
배포:
stage: deploy
script: make deploy-app
environment:
name: production
kubernetes:
namespace: production
이 구성은 배포
Job을 사용하여 production
환경으로, production
Kubernetes 네임스페이스를 사용하여 배포를 설정합니다.
추가 세부 정보:
- Kubernetes 구성은 GitLab에서 관리하는 Kubernetes 클러스터에서는 지원되지 않습니다.
관련 주제:
environment:deployment_tier
- GitLab 13.10에서 소개되었습니다.
deployment_tier
키워드를 사용하여 배포 환경의 티어를 지정합니다.
키워드 유형: Job 키워드. Job의 일부로만 사용할 수 있습니다.
가능한 입력: 다음 중 하나:
production
staging
testing
development
other
environment:deployment_tier
의 예:
deploy:
script: echo
environment:
name: customer-portal
deployment_tier: production
추가 세부 정보:
- 이 Job 정의에서 생성된 환경은 이 값에 기반하여 tier가 할당됩니다.
- 나중에 이 값이 추가되더라도 기존 환경은 그들의 티어가 업데이트되지 않습니다. 기존 환경은 환경 API를 통해 티어를 업데이트해야 합니다.
관련 주제:
동적 환경
CI/CD variables를 사용하여 동적으로 환경의 이름을 지정하세요.
예시:
deploy as review app:
stage: deploy
script: make deploy
environment:
name: review/$CI_COMMIT_REF_SLUG
url: https://$CI_ENVIRONMENT_SLUG.example.com/
deploy as review app
Job은 동적으로 review/$CI_COMMIT_REF_SLUG
환경을 생성하는 배포로 표시됩니다. $CI_COMMIT_REF_SLUG
는 러너가 설정한 CI/CD 변수입니다. $CI_ENVIRONMENT_SLUG
변수는 환경 이름을 기반으로 하지만 URL에 포함하기에 적합합니다. deploy as review app
Job이 pow
라는 브랜치에서 실행된다면, 이 환경은 https://review-pow.example.com/
과 같은 URL로 접근할 수 있을 것입니다.
일반적으로 브랜치에 대한 동적 환경을 생성하고 Review App으로 사용합니다. Review Apps를 사용하는 예시는 https://gitlab.com/gitlab-examples/review-apps-nginx/에서 확인할 수 있습니다.
extends
extends
를 사용하여 구성 섹션을 재사용하세요. 이는 YAML anchor의 대안이며 조금 더 유연하고 가독성이 좋습니다.
키워드 유형: Job 키워드. Job의 일부로만 사용할 수 있습니다.
가능한 입력:
- 파이프라인에서 다른 Job의 이름.
- 파이프라인에서 다른 Job 이름의 목록(배열).
extends
의 예:
.tests:
script: rake test
stage: test
only:
refs:
- branches
rspec:
extends: .tests
script: rake rspec
only:
variables:
- $RSPEC
이 예에서 rspec
Job은 .tests
템플릿 Job의 구성을 사용합니다.
파이프라인을 생성할 때, GitLab은:
- 키를 기반으로 역방향으로 깊은 병합을 수행합니다.
-
.tests
내용을rspec
Job에 병합합니다. - 키의 값은 병합하지 않습니다.
결과적으로 rspec
Job은 다음과 같이 됩니다:
rspec:
script: rake rspec
stage: test
only:
refs:
- branches
variables:
- $RSPEC
추가 세부 정보:
- GitLab 12.0 이상에서
extends
를 사용하여 여러 부모를 사용할 수 있습니다. -
extends
키워드는 11단계의 상속까지 지원하지만, 3단계 이상 사용을 피해야 합니다. - 위의 예시에서
.tests
는 숨겨진 Job이지만, 정규 Job에서도 구성을 확장할 수 있습니다.
관련 주제:
-
구성 섹션을 재사용하기 위해
extends
사용. -
포함된 구성 파일에서 구성을 재사용하기 위해
extends
사용.
hooks
-
GitLab 15.6에 Flag로 소개되었습니다.
ci_hooks_pre_get_sources_script
라는 Flag와 함께. 기본적으로 비활성화되어 있습니다. -
GitLab 15.10에서 일반적으로 사용 가능합니다.
ci_hooks_pre_get_sources_script
기능 플래그가 제거되었습니다.
hooks
를 사용하여 러너에서 작업 실행의 특정 단계에서 명령 목록을 지정하세요. 예를 들어 Git 리포지토리를 검색하기 전과 같은 작업의 일부 또는
default
섹션에서만 사용할 수 있습니다.
키워드 유형: Job 키워드. Job의 일부 또는
default
섹션에서만 사용할 수 있습니다.
가능한 입력:
- 후크 및 그들의 명령 목록의 해시. 사용 가능한 후크:
pre_get_sources_script
.
hooks:pre_get_sources_script
- 이슈인 GitLab 15.6에서
ci_hooks_pre_get_sources_script
라는 플래그로 도입되었습니다. 기본적으로 비활성화됩니다.- GitLab 15.10에서 일반적으로 사용 가능합니다.
ci_hooks_pre_get_sources_script
플래그가 제거되었습니다.
hooks:pre_get_sources_script
를 사용하여 Git 저장소 및 모든 하위 모듈을 복제하기 전에 러너에서 실행할 명령어 목록을 지정할 수 있습니다.
예를 들어 다음과 같은 방법으로 사용할 수 있습니다:
가능한 입력값: 다음을 포함하는 배열:
CI/CD 변수는 지원됩니다.
hooks:pre_get_sources_script
의 예시:
job1:
hooks:
pre_get_sources_script:
- echo 'hello job1 pre_get_sources_script'
script: echo 'hello job1 script'
관련 주제:
identity
- GitLab 16.9에서
google_cloud_support_feature_flag
라는 플래그로 도입되었습니다. 이 기능은 베타 단계입니다.
플래그: GitLab.com에서이 기능은 일부 사용자를 대상으로 사용할 수 있습니다. GitLab 전용에서는 이 기능을 사용할 수 없습니다.
이 기능은 베타 단계입니다. 이 기능을 테스트하는 사용자 목록에 참여하려면 대기 목록에 가입하세요.
identity
를 사용하여 ID 연합을 통해 제3자 서비스에 인증합니다.
키워드 타입: Job 키워드. job의 일부로만 또는 default:
섹션에 사용할 수 있습니다.
가능한 입력값: 식별자. 지원되는 공급자:
-
google_cloud
: Google Cloud. Google Cloud IAM 통합으로 구성해야 합니다.
identity
의 예시:
job_with_workload_identity:
identity: google_cloud
script:
- gcloud compute instances list
관련 주제:
id_tokens
- GitLab 15.7에서 도입되었습니다.
id_tokens
를 사용하여 JSON 웹 토큰 (JWT)을 만들어 제3자 서비스에 인증합니다. 이 방법으로 생성된 모든 JWT는 OIDC 인증을 지원합니다. 필요한 aud
하위 키워드는 JWT의 aud
클레임을 구성하는 데 사용됩니다.
가능한 입력값:
-
aud
클레임과 함께 토큰 이름.aud
는 다음을 지원합니다:- 단일 문자열.
- 문자열 배열.
- CI/CD 변수.
id_tokens
의 예시:
job_with_id_tokens:
id_tokens:
ID_TOKEN_1:
aud: https://vault.example.com
ID_TOKEN_2:
aud:
- https://gcp.com
- https://aws.com
SIGSTORE_ID_TOKEN:
aud: sigstore
script:
- command_to_authenticate_with_vault $ID_TOKEN_1
- command_to_authenticate_with_aws $ID_TOKEN_2
- command_to_authenticate_with_gcp $ID_TOKEN_2
관련 주제:
image
image
를 사용하여 작업이 실행되는 Docker 이미지를 지정합니다.
키워드 타입: Job 키워드. job의 일부로만 또는 default
섹션에 사용할 수 있습니다.
가능한 입력값: 이러한 형식 중 하나로 필요한 경우 레지스트리 경로를 포함하여 이미지의 이름:
-
<image-name>
(latest
태그와 함께<image-name>
사용하는 것과 동일) <image-name>:<tag>
<image-name>@<digest>
CI/CD 변수는 지원됩니다.
image
의 예시:
default:
image: ruby:3.0
rspec:
script: bundle exec rspec
rspec 2.7:
image: registry.example.com/my-group/my-project/ruby:2.7
script: bundle exec rspec
이 예에서 ruby:3.0
이미지는 파이프라인의 모든 작업에 대한 기본값입니다.
rspec 2.7
작업은 기본값을 사용하지 않으며 작업별 image
섹션으로 기본값을 오버라이드합니다.
관련 주제:
image:name
작업이 실행되는 Docker 이미지의 이름입니다. 단독으로 사용되는 image
와 유사합니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용하거나 default
섹션에서만 사용할 수 있습니다.
가능한 입력값: 이미지의 이름으로, 필요에 따라 레지스트리 경로를 포함한 다음 형식 중 하나여야 합니다:
-
<이미지-이름>
(latest
태그와 함께<이미지-이름>
사용한 것과 동일함) <이미지-이름>:<태그>
<이미지-이름>@<다이제스트>
CI/CD 변수는 지원됩니다.
image:name
의 예시:
test-job:
image:
name: "registry.example.com/my/image:latest"
script: echo "안녕, 세상아"
관련 주제:
image:entrypoint
컨테이너의 진입점으로 실행할 명령 또는 스크립트입니다.
Docker 컨테이너가 생성될 때, entrypoint
는 Docker의 --entrypoint
옵션으로 변환됩니다.
구문은 각 셸 토큰이 배열의 별도 문자열인 Dockerfile ENTRYPOINT
지시문과 유사합니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용하거나 default
섹션에서만 사용할 수 있습니다.
가능한 입력값:
- 문자열.
image:entrypoint
의 예시:
test-job:
image:
name: super/sql:experimental
entrypoint: [""]
script: echo "안녕, 세상아"
관련 주제:
image:docker
- GitLab 16.7에서 소개되었습니다. GitLab Runner 16.7 이상이 필요합니다.
user
입력 옵션은 GitLab 16.8에서 소개되었습니다.
image:docker
를 사용하여 GitLab Runner의 Docker 실행기에 옵션을 전달합니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용하거나 default
섹션에서만 사용할 수 있습니다.
가능한 입력값:
Docker 실행기의 옵션 해시로, 다음을 포함할 수 있습니다:
-
platform
: 가져올 이미지의 아키텍처를 선택합니다. 지정되지 않은 경우, 기본값은 호스트 실행기와 동일한 플랫폼입니다. -
user
: 컨테이너 실행 시 사용할 사용자명 또는 UID를 지정합니다.
image:docker
의 예시:
arm-sql-job:
script: echo "SQL 테스트 실행"
image:
name: super/sql:experimental
docker:
platform: arm64/v8
user: dave
추가 세부정보:
-
image:docker:platform
은docker pull --platform
옵션에 매핑됩니다. -
image:docker:user
은docker run --user
옵션에 매핑됩니다.
image:pull_policy
- GitLab 15.1에서 소개되었습니다.
ci_docker_image_pull_policy
라는 플래그가 필요합니다. 기본값은 비활성화되어 있습니다.- GitLab 15.2에서 GitLab.com 및 self-managed에서 사용 가능하도록 활성화되었습니다.
- GitLab 15.4에서 일반적으로 사용 가능하게 되었습니다. 기능 플래그
ci_docker_image_pull_policy
가 제거되었습니다. GitLab 15.1 버전 이상의 GitLab Runner가 필요합니다.
러너가 Docker 이미지를 가져오는 데 사용하는 풀 정책입니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용하거나 default
섹션에서만 사용할 수 있습니다.
가능한 입력값:
- 단일 풀 정책 또는 배열 내에서 여러 풀 정책입니다.
always
,if-not-present
, 또는never
일 수 있습니다.
image:pull_policy
의 예시:
job1:
script: echo "단일 풀 정책"
image:
name: ruby:3.0
pull_policy: if-not-present
job2:
script: echo "여러 풀 정책"
image:
name: ruby:3.0
pull_policy: [always, if-not-present]
추가 세부정보:
- 러너가 정의된 풀 정책을 지원하지 않는 경우, 작업은 다음과 유사한 오류와 함께 실패합니다:
ERROR: Job failed (system failure): the configured PullPolicies ([always]) are not allowed by AllowedPullPolicies ([never])
.
관련 주제:
inherit
- GitLab 12.9에서 소개되었습니다.
inherit
를 사용하여 기본 키워드 및 변수의 상속을 제어합니다.
inherit:default
inherit:default
를 사용하여 기본 키워드의 상속을 제어합니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.
가능한 입력값:
- 모든 기본 키워드의 상속을 활성화 또는 비활성화하려면
true
(기본값) 또는false
. - 상속할 특정 기본 키워드의 목록.
inherit:default
의 예시:
default:
retry: 2
image: ruby:3.0
interruptible: true
job1:
script: echo "이 작업은 어떤 기본 키워드도 상속받지 않습니다."
inherit:
default: false
job2:
script: echo "이 작업은 두 가지 기본 키워드만 상속받습니다. 'interruptible'은 상속받지 않습니다."
inherit:
default:
- retry
- image
추가 세부 정보:
- 상속받을 기본 키워드를 한 줄에 나열할 수도 있습니다:
default: [키워드1, 키워드2]
inherit:variables
inherit:variables
를 사용하여 전역 변수의 상속을 제어합니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.
가능한 입력값:
- 모든 전역 변수의 상속을 활성화 또는 비활성화하려면
true
(기본값) 또는false
. - 상속할 특정 변수의 목록.
inherit:variables
의 예시:
variables:
VARIABLE1: "이것은 변수 1입니다"
VARIABLE2: "이것은 변수 2입니다"
VARIABLE3: "이것은 변수 3입니다"
job1:
script: echo "이 작업은 어떤 전역 변수도 상속받지 않습니다."
inherit:
variables: false
job2:
script: echo "이 작업은 두 가지 전역 변수만 상속받습니다. 'VARIABLE3'은 상속받지 않습니다."
inherit:
variables:
- VARIABLE1
- VARIABLE2
추가 세부 정보:
- 상속받을 전역 변수를 한 줄에 나열할 수도 있습니다:
variables: [VARIABLE1, VARIABLE2]
interruptible
- GitLab 12.3에서 소개되었습니다.
- 동일한 ref에 대한 새 커밋으로 시작된 새 파이프라인이 있을 때 자동으로 취소되는 중복 파이프라인 기능을 구성하려면
interruptible
을 사용하세요.- 동일한 ref에 대한 새 커밋으로 시작된 새 파이프라인이 있을 때 자동으로 취소되는 중복 파이프라인 기능을 구성하려면
interruptible
을 사용하세요.
interruptible
를 사용하여 자동으로 취소되는 중복 파이프라인 기능을 구성하여 작업이 완료되기 전에 작업이 취소되도록 할 수 있습니다. 이 기능이 비활성화된 경우 키워드는 작동하지 않습니다.
Running 작업은 interruptible: true
로 구성되어 있고 다음과 같을 때에만 취소됩니다.
-
interruptible: false
로 구성된 작업이 어느 시점에서든 시작되지 않았을 때.interruptible: false
로 구성된 작업이 시작되면 전체 파이프라인은 더 이상 취소되지 않습니다.- 파이프라인이 하위 파이프라인을 트리거했지만 하위 파이프라인에
interruptible: false
로 구성된 작업이 아직 시작되지 않았을 경우 하위 파이프라인도 취소됩니다.
- 파이프라인이 하위 파이프라인을 트리거했지만 하위 파이프라인에
- 새로운 파이프라인이 새로운 변경 사항이 있는 커밋에 대한 것일 때. 자동으로 취소되는 중복 파이프라인 기능은 동일한 커밋에 대한 파이프라인을 실행하려면 UI에서 파이프라인 실행을 선택하는 경우에는 작동하지 않습니다.
아직 시작되지 않은 작업은 구성에 관계없이 항상 interruptible: true
로 간주됩니다. interruptible
구성은 작업이 시작된 후에만 고려됩니다.
키워드 유형: 작업 키워드. 작업이나 default
섹션의 일부로만 사용할 수 있습니다.
가능한 입력값:
-
true
또는false
(기본값).
interruptible
의 예시:
stages:
- stage1
- stage2
- stage3
step-1:
stage: stage1
script:
- echo "취소될 수 있습니다."
interruptible: true
step-2:
stage: stage2
script:
- echo "취소될 수 없습니다."
step-3:
stage: stage3
script:
- echo "step-2가 취소되지 않으므로 이 작업은 실제로 취소되지 않습니다. 단, 이 작업은 interruptible로 설정되어 있습니다."
interruptible: true
이 예시에서 새로운 파이프라인은 다음과 같은 상황에서 실행 중인 파이프라인을:
-
step-1
이 실행 중이거나 대기 중인 경우 취소됩니다. -
step-2
가 시작된 후에는 취소되지 않습니다.
추가 세부 정보:
- 작업이 시작된 후에 안전하게 취소할 수 있는 경우에만
interruptible: true
로 설정하세요. 이는 빌드 작업과 같은 작업에 해당합니다. 부분적인 배포를 방지하기 위해 배포 작업은 일반적으로 취소되지 않아야 합니다. - 자동으로 취소되는 중복 파이프라인** 기능을 막기 위해 파이프라인이 자동으로 취소되지 않도록 하려면 파이프라인의 첫 번째 단계에
interruptible: false
로 선택할 수 있는 선택적인 수동 작업을 추가할 수 있습니다. 사용자가 작업을 시작하면 자동으로 취소되는 중복 파이프라인 기능에 의해 파이프라인을 취소할 수 없습니다. -
트리거 작업에서
interruptible
을 사용하는 경우:- 트리거된 하위 파이프라인은 트리거 작업의
interruptible
구성에 영향을 받지 않습니다. -
workflow:auto_cancel
이conservative
로 설정된 경우 트리거 작업의interruptible
구성은 영향을 미치지 않습니다. -
workflow:auto_cancel
이interruptible
로 설정된 경우interruptible: true
로 설정된 트리거 작업은 자동으로 취소될 수 있습니다.
- 트리거된 하위 파이프라인은 트리거 작업의
needs
- GitLab 12.2에서 도입되었습니다.
- GitLab 12.3에서
needs
배열 내의 작업 수 최대값이 5에서 50으로 상향 조정되었습니다.- GitLab 12.8에서
needs: []
가 작업을 즉시 시작하도록 합니다.- GitLab 14.2에서 구성 중인 작업과 동일한 단계의 작업을 참조할 수 있게 되었습니다.
needs
를 사용하여 작업을 순서에 구애받지 않고 실행합니다. needs
를 사용하는 작업 간의 관계는 유향 비순환 그래프로 시각화할 수 있습니다.
단계 순서를 무시하고 일부 작업을 완료를 기다리지 않고 실행할 수 있습니다. 여러 단계에 걸친 작업은 동시에 실행될 수 있습니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.
가능한 입력값:
- 작업 배열.
- 파이프라인이 생성되자마자 작업을 시작하도록 빈 배열(
[]
).
needs
의 예시:
linux:build:
stage: build
script: echo "Building linux..."
mac:build:
stage: build
script: echo "Building mac..."
lint:
stage: test
needs: []
script: echo "Linting..."
linux:rspec:
stage: test
needs: ["linux:build"]
script: echo "Running rspec on linux..."
mac:rspec:
stage: test
needs: ["mac:build"]
script: echo "Running rspec on mac..."
production:
stage: deploy
script: echo "Running production..."
environment: production
이 예시에서 4가지 실행 경로가 생성됩니다:
- Linter:
lint
작업은needs: []
로 인해build
단계의 완료를 기다리지 않고 즉시 실행됩니다. - Linux 경로:
linux:rspec
작업은linux:build
작업이 완료되는 즉시 실행되며mac:build
의 완료를 기다리지 않습니다. - macOS 경로:
mac:rspec
작업은mac:build
작업이 완료되는 즉시 실행되며linux:build
의 완료를 기다리지 않습니다. -
production
작업은 이전 모든 작업(linux:build
,linux:rspec
,mac:build
,mac:rspec
)이 완료되는 즉시 실행됩니다.
추가 세부정보:
- 단일 작업이
needs
배열에 가질 수 있는 최대 작업 수는 제한됩니다: - 만약
needs
가parallel
키워드를 사용하는 작업을 참조한다면, 이는 병렬로 생성된 모든 작업에 의존하며 단순히 하나의 작업에만 의존하지 않습니다. 또한 기본적으로 모든 병렬 작업에서 artifact를 다운로드합니다. 만약 artifact가 동일한 이름을 가진다면 서로 덮어씁니다. 그리고 마지막으로 다운로드한 artifact만 저장됩니다.- 병렬화된 작업의 일부에만(
parallel:matrix
를 사용하지 않고 모든 병렬화된 작업에 대해)needs
를 참조하려면needs:parallel:matrix
를 사용하세요.
- 병렬화된 작업의 일부에만(
- GitLab 14.1 및 이후에서는 구성 중인 작업과 동일한 단계의 작업을 참조할 수 있습니다. 이 기능은 GitLab.com에서 활성화되어 있으며 프로덕션에 사용할 준비가 되어 있습니다. 자체 관리형 GitLab 14.2 및 이후에서는 이 기능이 기본적으로 사용할 수 있습니다.
- GitLab 14.0 및 이전에서는 이전 단계의 작업만 참조할 수 있습니다.
needs
키워드를 사용하는 모든 작업에 대해 단계를 명시적으로 정의해야 하거나 작업의needs
섹션에서 참조되어야 합니다. -
needs
가only
,except
, 또는rules
때문에 파이프라인에 추가되지 않을 수도 있는 작업을 참조한다면, 파이프라인 생성에 실패할 수 있습니다. 실패한 파이프라인 생성을 해결하려면needs:optional
키워드를 사용하세요. - 파이프라인에
needs: []
작업과 .pre 단계의 작업이 모두 있는 경우, 파이프라인이 생성되자마자 모두 시작됩니다.needs: []
를 가진 작업은 즉시 시작되고, .pre 단계의 작업도 즉시 시작됩니다.
needs:artifacts
- GitLab 12.6에서 도입되었습니다.
작업이 needs
를 사용하는 경우 기본적으로 이전 단계의 모든 artifacts를 다운로드하지 않습니다. 왜냐하면 needs
를 사용하는 작업은 이전 단계가 완료되기 전에 시작할 수 있습니다. needs
를 사용하면 needs
구성에 나열된 작업에서만 artifacts를 다운로드할 수 있습니다.
needs
를 사용하는 작업에서 artifacts를 다운로드하는 시기를 제어하려면 artifacts: true
(기본값) 또는 artifacts: false
를 사용합니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다. needs:job
와 함께 사용해야 합니다.
가능한 입력:
-
true
(기본값) 또는false
.
needs:artifacts
의 예시:
test-job1:
stage: test
needs:
- job: build_job1
artifacts: true
test-job2:
stage: test
needs:
- job: build_job2
artifacts: false
test-job3:
needs:
- job: build_job1
artifacts: true
- job: build_job2
- build_job3
이 예시에서:
-
test-job1
작업은build_job1
의 artifacts를 다운로드합니다. -
test-job2
작업은build_job2
의 artifacts를 다운로드하지 않습니다. -
test-job3
작업은artifacts
가true
또는 기본값인 경우 세 작업의 artifacts를 모두 다운로드합니다.
추가 세부정보:
- 동일한 작업에서
needs
와dependencies
를 결합해서는 안 됩니다.
needs:project
- GitLab 12.7에서 도입되었습니다.
needs:project
를 사용하여 다른 파이프라인에서 최대 다섯 개의 작업에서 artifacts를 다운로드합니다. artifacts는 지정된 ref에 대한 지정된 작업의 최신 성공에 대해 다운로드됩니다. 여러 작업을 지정하려면 needs
키워드 아래에 각 작업을 별도의 배열 항목으로 추가하면 됩니다.
ref에 대해 파이프라인이 실행 중인 경우, needs:project
를 사용하는 작업은 파이프라인이 완료되기를 기다리지 않습니다. 대신, artifacts는 지정된 작업의 최신 성공 실행에서 다운로드됩니다.
needs:project
는 job
, ref
, artifacts
와 함께 사용해야 합니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.
가능한 입력:
-
needs:project
: 네임스페이스와 그룹을 포함한 전체 프로젝트 경로. -
job
: artifacts를 다운로드할 작업. -
ref
: artifacts를 다운로드할 ref. -
artifacts
: artifacts를 다운로드하려면 반드시true
여야 합니다.
needs:project
의 예시:
build_job:
stage: build
script:
- ls -lhR
needs:
- project: namespace/group/project-name
job: build-1
ref: main
artifacts: true
- project: namespace/group/project-name-2
job: build-2
ref: main
artifacts: true
이 예시에서 build_job
은 group/project-name
및 group/project-name-2
프로젝트의 main
브랜치에서 최신 성공한 build-1
및 build-2
작업에서 artifacts를 다운로드합니다.
GitLab 13.3 이후, needs:project
에서 CI/CD 변수를 사용할 수 있습니다. 예를 들어:
build_job:
stage: build
script:
- ls -lhR
needs:
- project: $CI_PROJECT_PATH
job: $DEPENDENCY_JOB_NAME
ref: $ARTIFACTS_DOWNLOAD_REF
artifacts: true
추가 세부정보:
- 현재 프로젝트의 다른 파이프라인에서 artifacts를 다운로드하려면
project
를 현재 프로젝트와 동일하게 설정하되, 현재 파이프라인과 다른 ref를 사용해야 합니다. 동일한 ref에서 동시에 실행되는 파이프라인이 artifacts를 덮어쓸 수 있습니다. - 파이프라인을 실행하는 사용자는 그룹 또는 프로젝트에 대해 적어도 Reporter 역할이 있거나, 그룹/프로젝트가 공개 가시성을 가져야 합니다.
-
trigger
와 함께needs:project
를 동일한 작업에서 사용할 수 없습니다. -
needs:project
를 사용하여 다른 파이프라인에서 artifacts를 다운로드할 때, 해당 작업을 기다리지 않습니다. 유향 비순환 그래프 동작은 동일한 파이프라인의 작업으로 제한됩니다. 다운로드해야 하는 작업이 다른 파이프라인에서 완료되기 전에 필요로 하는 작업이 실행되지 않도록 주의하십시오. -
parallel
에서 실행되는 작업에서 artifacts를 다운로드할 수 없습니다. -
project
,job
,ref
에서 CI/CD 변수의 지원은 GitLab 13.3에서 도입되었습니다. GitLab 13.4에서 기능 플래그 제거되었습니다.
관련 주제:
-
부모-자식 파이프라인 사이에서 artifacts를 다운로드하려면
needs:pipeline:job
를 사용합니다.
needs:pipeline:job
- GitLab 13.7에서 소개되었습니다.
하위 파이프라인은 부모-자식 파이프라인 계층 구조 내 동일한 부모-자식 파이프라인이나 다른 하위 파이프라인의 작업에서 아티팩트를 다운로드할 수 있습니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.
가능한 입력값:
-
needs:pipeline
: 파이프라인 ID. 동일한 부모-자식 파이프라인 계층 구조에 포함된 파이프라인이어야 합니다. -
job
: 아티팩트를 다운로드할 작업명.
needs:pipeline:job
의 예시:
-
부모 파이프라인 (
.gitlab-ci.yml
):create-artifact: stage: build script: echo "샘플 아티팩트" > artifact.txt artifacts: paths: [artifact.txt] child-pipeline: stage: test trigger: include: child.yml strategy: depend variables: PARENT_PIPELINE_ID: $CI_PIPELINE_ID
-
하위 파이프라인 (
child.yml
):use-artifact: script: cat artifact.txt needs: - pipeline: $PARENT_PIPELINE_ID job: create-artifact
이 예시에서 부모 파이프라인의 create-artifact
작업은 일부 아티팩트를 생성합니다. child-pipeline
작업은 하위 파이프라인을 트리거하고 CI_PIPELINE_ID
변수를 새 PARENT_PIPELINE_ID
변수로 하위 파이프라인으로 전달합니다. 하위 파이프라인은 needs:pipeline
에서 해당 변수를 사용하여 부모 파이프라인에서 아티팩트를 다운로드할 수 있습니다.
추가 세부 정보:
-
pipeline
속성은 현재 파이프라인 ID($CI_PIPELINE_ID
)를 허용하지 않습니다. 현재 파이프라인의 작업에서 아티팩트를 다운로드하려면needs:artifacts
를 사용하세요.
needs:optional
- GitLab 13.10에서 소개되었습니다.
- 기능 플래그가 제거되었습니다. (GitLab 14.0)
때때로 파이프라인에 존재하지 않는 작업이 필요한 경우, optional: true
을 needs
구성에 추가하세요. 정의되지 않은 경우, optional: false
가 기본값입니다.
rules
, only
, 또는 except
를 사용하고 include
로 추가된 작업은 항상 파이프라인에 추가되지 않을 수 있습니다. GitLab은 파이프라인을 시작하기 전에 needs
관계를 확인합니다.
-
needs
항목에optional: true
가 있고 필요한 작업이 파이프라인에 있으면, 해당 작업이 완료될 때까지 대기합니다. - 필요한 작업이 존재하지 않는 경우, 다른 모든 필요한 요구사항이 충족되면 작업을 시작할 수 있습니다.
-
needs
섹션이 옵션이 가능한 작업만 포함하고, 이를 파이프라인에 추가하지 않은 경우, 작업은 즉시 시작합니다 (빈needs
항목과 동일하게needs: []
). - 필요한 작업이
optional: false
을 가지고 있지만 파이프라인에 추가되지 않은 경우, 파이프라인은 시작하면서 다음과 유사한 오류가 발생합니다:'job1' 작업이 'job2' 작업이 필요하지만 파이프라인에 추가되지 않았습니다
.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.
needs:optional
의 예시:
build-job:
stage: build
test-job1:
stage: test
test-job2:
stage: test
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
deploy-job:
stage: deploy
needs:
- job: test-job2
optional: true
- job: test-job1
environment: production
review-job:
stage: deploy
needs:
- job: test-job2
optional: true
environment: review
이 예시에서:
-
build-job
,test-job1
, 그리고test-job2
는 순서대로 시작합니다. - 브랜치가 기본 브랜치인 경우,
test-job2
가 파이프라인에 추가되어:-
deploy-job
은test-job1
과test-job2
가 완료될 때까지 대기합니다. -
review-job
은test-job2
가 완료될 때까지 대기합니다.
-
- 브랜치가 기본 브랜치가 아닌 경우,
test-job2
가 파이프라인에 추가되지 않으므로:-
deploy-job
은test-job1
만 완료될 때까지 대기하고 누락된test-job2
를 기다리지 않습니다. -
review-job
에 다른 필요한 작업이 없으며 즉시 시작합니다 (needs: []
와 동일한 시간에 시작됨).
-
needs:pipeline
needs:pipeline
키워드를 사용하여 상위 파이프라인에서 작업으로 파이프라인 상태를 미러링할 수 있습니다. 기본 브랜치의 최신 파이프라인 상태가 작업에 복제됩니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.
가능한 입력값:
- 전체 프로젝트 경로, 네임스페이스 및 그룹을 포함합니다. 프로젝트가 동일한 그룹 또는 네임스페이스에 있으면
project
키워드에서 그들을 생략할 수 있습니다. 예:project: group/project-name
또는project: project-name
.
needs:pipeline
의 예시:
upstream_status:
stage: test
needs:
pipeline: other/project
추가 세부 정보:
-
job
키워드를needs:pipeline
에 추가하면 작업이 더 이상 파이프라인 상태를 미러링하지 않습니다. 동작은needs:pipeline:job
로 변경됩니다.
needs:parallel:matrix
- GitLab 16.3에서 소개되었습니다.
작업은 parallel:matrix
를 사용하여 파이프라인에서 작업을 여러 번 병렬로 실행할 수 있지만 각 작업 인스턴스마다 다른 변수 값을 사용할 수 있습니다.
needs:parallel:matrix
를 사용하여 병렬화된 작업에 따라 순서에 맞지 않게 작업을 실행합니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다. needs:job
와 함께 사용해야 합니다.
가능한 입력값: 변수 해시 배열:
- 변수와 값을
parallel:matrix
작업에서 정의한 변수 및 값에서 선택해야 합니다.
needs:parallel:matrix
의 예시:
linux:build:
stage: build
script: echo "linux 빌드 중..."
parallel:
matrix:
- PROVIDER: aws
STACK:
- monitoring
- app1
- app2
linux:rspec:
stage: test
needs:
- job: linux:build
parallel:
matrix:
- PROVIDER: aws
STACK: app1
script: echo "linux에서 rspec 실행 중..."
위의 예시는 다음과 같은 작업을 생성합니다:
linux:build: [aws, monitoring]
linux:build: [aws, app1]
linux:build: [aws, app2]
linux:rspec
linux:rspec
작업은 linux:build: [aws, app1]
작업이 완료되자마자 실행됩니다.
관련 주제:
추가 정보:
-
needs:parallel:matrix
의 매트릭스 변수 순서는 필요한 작업의 매트릭스 변수 순서와 일치해야 합니다. 예를 들어, 위의 예시의linux:rspec
작업에서 변수의 순서를 뒤집으면 잘못됩니다:linux:rspec: stage: test needs: - job: linux:build parallel: matrix: - STACK: app1 # 변수 순서가 `linux:build`와 일치하지 않아 잘못된 예시입니다. PROVIDER: aws script: echo "linux에서 rspec 실행 중..."
pages
pages
를 사용하여 GitLab Pages 작업을 정의하여 정적 콘텐츠를 GitLab에 업로드합니다. 그런 다음 해당 콘텐츠가 웹 사이트로 게시됩니다.
다음을 수행해야 합니다:
키워드 유형: 작업 이름.
pages
의 예시:
pages:
stage: deploy
script:
- mv my-html-content public
artifacts:
paths:
- public
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
environment: production
이 예시는 my-html-content/
디렉토리를 public/
로 이름을 변경합니다.
이 디렉토리는 artifact로 내보내어 GitLab Pages와 함께 게시됩니다.
pages:publish
- GitLab 16.1에서 소개되었습니다.
publish
를 사용하여 pages
작업의 콘텐츠 디렉토리를 구성합니다.
키워드 유형: 작업 키워드. pages
작업의 일부로만 사용할 수 있습니다.
가능한 입력값: Pages 콘텐츠가 포함된 디렉토리 경로.
publish
의 예시:
pages:
stage: deploy
script:
- npx @11ty/eleventy --input=path/to/eleventy/root --output=dist
artifacts:
paths:
- dist
publish: dist
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
environment: production
이 예시에서는 Eleventy를 사용하여 정적 웹사이트를 생성하고,
생성된 HTML 파일을 dist/
디렉토리에 출력합니다. 이 디렉토리는 artifact로 내보내어
GitLab Pages와 함께 게시됩니다.
pages:pages.path_prefix
-
GitLab 16.7에서
pages_multiple_versions_setting
이라는 플래그와 함께 실험으로 소개되었습니다. 기본적으로 이 기능은 self-managed GitLab에서 사용할 수 없습니다. 사용하려면 관리자가pages_multiple_versions_setting
이라는 피쳐 플래그를 활성화해야 합니다. GitLab.com과 GitLab Dedicated에서는 이 기능을 사용할 수 없습니다. 이 기능은 실제 운영에 사용하기에는 준비되지 않았습니다.
pages.path_prefix
를 사용하여 GitLab Pages를 여러 버전으로 배포하기 위한 경로 접두사를 구성합니다.
키워드 유형: 작업 키워드. pages
작업의 일부로만 사용할 수 있습니다.
가능한 입력값:
pages.path_prefix
의 예시:
pages:
stage: deploy
script:
- echo "${CI_PAGES_URL}/${CI_COMMIT_BRANCH}"로 페이지에 접근할 수 있습니다.
pages:
path_prefix: "$CI_COMMIT_BRANCH"
artifacts:
paths:
- public
이 예시에서 각 브랜치별로 다른 페이지 배포가 생성됩니다.
parallel
- GitLab 15.9에서 소개되었으며,
parallel
의 최대 값이 50에서 200으로 증가했습니다.
하나의 파이프라인에서 작업을 병렬로 여러 번 실행하려면 parallel
을 사용합니다.
여러 개의 러너가 존재해야 하거나, 단일 러너가 여러 작업을 동시에 실행하도록 구성되어야 합니다.
병렬 작업은 job_name 1/N
에서 job_name N/N
까지 차례대로 명명됩니다.
키워드 유형: Job keyword. 작업의 일부로만 사용할 수 있습니다.
가능한 입력:
-
1
에서200
까지의 숫자 값
parallel
예시:
test:
script: rspec
parallel: 5
이 예시는 병렬로 실행되는 5개의 작업을 생성하며, test 1/5
에서 test 5/5
까지 명명됩니다.
추가 세부 정보:
- 각 병렬 작업에는
CI_NODE_INDEX
및CI_NODE_TOTAL
사전 정의 CI/CD 변수가 설정됩니다. -
parallel
을 사용하는 작업이 있는 파이프라인은:- 사용 가능한 러너보다 병렬로 실행되는 작업이 많을 수 있습니다. 초과된 작업은 대기 중인 상태로 표시되어 사용 가능한 러너를 기다립니다.
- 너무 많은 작업이 생성되어 파이프라인이
job_activity_limit_exceeded
오류로 실패할 수 있습니다. active 파이프라인에 존재할 수 있는 최대 작업 수는 인스턴스 수준에서 제한됩니다.
관련 주제:
parallel:matrix
- GitLab 13.3에서 소개됨.
- 작업 명명 스타일이 GitLab 13.4에서 개선되었습니다.
- GitLab 15.9에서 도입되었으며, 순열의 최대 수가 50에서 200으로 증가했습니다.
하나의 파이프라인에서 작업을 병렬로 여러 번 실행하려면 parallel:matrix
를 사용하지만 작업의 각 인스턴스마다 다른 변수 값으로 실행합니다.
여러 개의 러너가 존재해야 하거나, 단일 러너가 여러 작업을 동시에 실행하도록 구성되어야 합니다.
키워드 유형: Job keyword. 작업의 일부로만 사용할 수 있습니다.
가능한 입력: 변수 해시 배열
- 변수 이름에는 숫자, 문자 및 밑줄(
_
)만 사용할 수 있습니다. - 값은 문자열이거나 문자열 배열이어야 합니다.
- 순열의 수는 200을 초과할 수 없습니다.
parallel:matrix
예시:
deploystacks:
stage: deploy
script:
- bin/deploy
parallel:
matrix:
- PROVIDER: aws
STACK:
- monitoring
- app1
- app2
- PROVIDER: ovh
STACK: [monitoring, backup, app]
- PROVIDER: [gcp, vultr]
STACK: [data, processing]
environment: $PROVIDER/$STACK
이 예시는 PROVIDER
및 STACK
의 각기 다른 값으로 10개의 병렬 deploystacks
작업을 생성합니다.
deploystacks: [aws, monitoring]
deploystacks: [aws, app1]
deploystacks: [aws, app2]
deploystacks: [ovh, monitoring]
deploystacks: [ovh, backup]
deploystacks: [ovh, app]
deploystacks: [gcp, data]
deploystacks: [gcp, processing]
deploystacks: [vultr, data]
deploystacks: [vultr, processing]
추가 세부 정보:
-
parallel:matrix
작업은 작업 이름에 변수 값을 추가하여 작업을 서로 구별합니다. 그러나 큰 값은 이름이 제한을 초과할 수 있습니다:- 작업 이름은 255자 이하여야 합니다.
-
needs
를 사용할 때 작업 이름은 128자 이하여야 합니다.
관련 주제:
추가 세부 정보:
-
동일한 변수 값으로 여러 매트릭스 구성을 생성할 수 없습니다. 작업 이름은 변수 이름이 아닌 변수 값에서 생성되므로 동일한 값을 가진 매트릭스 항목은 서로 덮어씁니다.
예를 들어, 이
test
구성은 동일한 작업을 생성하려고 시도하지만OS2
버전이OS
버전을 덮어씁니다:test: parallel: matrix: - OS: [ubuntu] PROVIDER: [aws, gcp] - OS2: [ubuntu] PROVIDER: [aws, gcp]
릴리스
- 소개됨 in GitLab 13.2.
릴리스
를 사용하여 릴리스를 생성합니다.
릴리스 작업은 release-cli
에 액세스해야 합니다.
이것은 $PATH
에 있어야 합니다.
만약 도커 실행자를 사용한다면,
GitLab 컨테이너 레지스트리로부터 이 이미지를 사용할 수 있습니다: registry.gitlab.com/gitlab-org/release-cli:latest
만약 쉘 실행자나 유사한 실행자를 사용한다면,
서버에 release-cli
를 설치해야 합니다. 이 서버는 러너가 등록된 곳입니다.
키워드 타입: Job 키워드. 이것은 오직 작업의 일부로만 사용할 수 있습니다.
가능한 입력: 릴리스
의 서브키:
tag_name
-
tag_message
(선택 사항) -
name
(선택 사항) description
-
ref
(선택 사항) -
milestones
(선택 사항) -
released_at
(선택 사항) -
assets:links
(선택 사항)
릴리스
키워드의 예시:
release_job:
stage: release
image: registry.gitlab.com/gitlab-org/release-cli:latest
rules:
- if: $CI_COMMIT_TAG # 태그가 수동으로 생성될 때 이 작업을 실행합니다.
script:
- echo "릴리스 작업 실행 중."
release:
tag_name: $CI_COMMIT_TAG
name: '릴리스 $CI_COMMIT_TAG'
description: '릴리스 생성 - release-cli 사용.'
이 예시는 다음 상황에서 릴리스를 생성합니다:
- Git 태그를 푸시할 때.
- 코드 > 태그에서 UI로 Git 태그를 추가할 때.
추가 세부 정보:
-
트리거 작업을 제외한 모든 릴리스 작업에는
script
키워드가 포함되어야 합니다. 릴리스 작업은 스크립트 명령어의 출력을 사용할 수 있습니다. 만약 스크립트가 필요하지 않다면, 플레이스홀더를 사용할 수 있습니다:script: - echo "릴리스 작업"
이 요구사항을 없애기 위한 이슈가 존재합니다.
-
릴리스
섹션은script
키워드 이후,after_script
이전에 실행됩니다. - 릴리스는 작업의 메인 스크립트가 성공한 경우에만 생성됩니다.
- 만약 릴리스가 이미 존재한다면, 업데이트되지 않고
릴리스
키워드가 포함된 작업이 실패합니다.
관련 주제:
릴리스:tag_name
필수 사항입니다. 릴리스를 위한 Git 태그입니다.
만약 프로젝트에 해당 태그가 아직 존재하지 않는다면, 릴리스 생성과 동시에 태그가 만들어집니다. 새로운 태그는 파이프라인과 연관된 SHA를 사용합니다.
키워드 타입: Job 키워드. 오직 작업의 일부로만 사용할 수 있습니다.
가능한 입력:
- 태그 이름.
CI/CD 변수는 지원됩니다.
릴리스:tag_name
의 예시:
프로젝트에 새로운 태그가 추가될 때 릴리스를 생성하기 위해서:
-
tag_name
으로$CI_COMMIT_TAG
CI/CD 변수를 사용합니다. - 작업이 새로운 태그만을 위해 실행되도록
rules:if
를 구성합니다.
job:
script: echo "새 태그에 대한 릴리스 작업 실행 중."
release:
tag_name: $CI_COMMIT_TAG
description: '릴리스 설명'
rules:
- if: $CI_COMMIT_TAG
릴리스와 동시에 새로운 태그를 만들기 위해서는,rules
에서 작업이 새로운 태그만을 위해 실행되도록 구성되지 않아야 합니다. 의미론적 버전 예시:
job:
script: echo "릴리스 작업 실행 및 새로운 태그 생성 중."
release:
tag_name: ${MAJOR}_${MINOR}_${REVISION}
description: '릴리스 설명'
rules:
- if: $CI_PIPELINE_SOURCE == "schedule"
릴리스:tag_message
- GitLab 15.3에서 소개됨.
release-cli
v0.12.0 이후로 지원됩니다.
태그가 존재하지 않는 경우, 새로 만들어진 태그는 tag_message
로 지정된 메시지로 주석이 달립니다.
생략될 경우, 가벼운 태그가 만들어집니다.
키워드 타입: Job 키워드. 오직 작업의 일부로만 사용할 수 있습니다.
가능한 입력:
- 텍스트 문자열.
릴리스:tag_message
의 예시:
release_job:
stage: release
release:
tag_name: $CI_COMMIT_TAG
description: '릴리스 설명'
tag_message: '주석이 달린 태그 메시지'
release:name
릴리스 이름. 생략하면 release: tag_name
의 값을 가지게 됩니다.
키워드 유형: 잡 키워드. 잡의 일부로만 사용할 수 있습니다.
가능한 입력값:
- 텍스트 문자열.
release:name
의 예시:
release_job:
stage: release
release:
name: '릴리스 $CI_COMMIT_TAG'
release:description
릴리스의 장문 설명.
키워드 유형: 잡 키워드. 잡의 일부로만 사용할 수 있습니다.
가능한 입력값:
- 장문 설명이 있는 문자열.
- 설명을 담고 있는 파일의 경로. GitLab 13.7에서 소개됨.
- 파일 위치는 프로젝트 디렉토리(
$CI_PROJECT_DIR
)를 기준으로 합니다. - 파일이 심볼릭 링크인 경우,
$CI_PROJECT_DIR
에 있어야 합니다. -
./path/to/file
및 파일 이름에는 공백이 포함될 수 없습니다.
- 파일 위치는 프로젝트 디렉토리(
release:description
의 예시:
job:
release:
tag_name: ${MAJOR}_${MINOR}_${REVISION}
description: './path/to/CHANGELOG.md'
추가 상세정보:
-
description
은release-cli
를 실행하는 셸에서 평가됩니다. 설명을 정의하는 데 CI/CD 변수를 사용할 수 있지만, 일부 셸은 변수를 참조하는 데 다른 구문을 사용할 수 있습니다. 마찬가지로, 일부 셸은 특수 문자를 이스케이핑하는 것을 요구할 수 있습니다. 예를 들어, 역따옴표(\
`)는 백슬래시(\
)로 이스케이핑해야 할 수 있습니다.
release:ref
release: tag_name
이 아직 존재하지 않는 경우, 릴리스의 ref
.
키워드 유형: 잡 키워드. 잡의 일부로만 사용할 수 있습니다.
가능한 입력값:
- 커밋 SHA, 다른 태그 이름 또는 브랜치 이름.
release:milestones
릴리스가 연관된 각 마일스톤의 제목.
release:released_at
릴리스가 준비된 날짜와 시간.
가능한 입력값:
- ISO 8601 형식으로 표현된 따옴표로 감싸인 날짜.
release:released_at
의 예시:
released_at: '2021-03-15T08:00:00Z'
추가 상세정보:
- 정의되지 않은 경우, 현재 날짜와 시간이 사용됩니다.
release:assets:links
- GitLab 13.12에서 소개됨.
release:assets:links
를 사용하여 릴리스에 자산 링크를 포함시킵니다.
release-cli
버전 v0.4.0 이상이 필요합니다.
release:assets:links
의 예시:
assets:
links:
- name: '자산1'
url: 'https://example.com/assets/1'
- name: '자산2'
url: 'https://example.com/assets/2'
filepath: '/pretty/url/1' # 선택 사항
link_type: 'other' # 선택 사항
resource_group
- GitLab 12.7에서 소개됨.
resource_group
은 동일 프로젝트에 대한 여러 파이프라인에서 작업이 상호배타적임을 보장하는 리소스 그룹을 생성하는 데 사용합니다.
예를 들어, 동일한 리소스 그룹에 속한 여러 작업이 동시에 대기열에 들어가면, 작업 중 하나만 시작됩니다. 다른 작업은 resource_group
이 비워질 때까지 기다립니다.
리소스 그룹은 다른 프로그래밍 언어의 세마포어와 유사하게 작동합니다.
배포 환경에 대한 작업 동시성을 전략적으로 제어하기 위해 프로세스 모드를 선택할 수 있습니다. 기본 프로세스 모드는 unordered
입니다. 리소스 그룹의 프로세스 모드를 변경하려면 API를 사용하여 기존 리소스 그룹을 편집하는 요청을 보내야 합니다.
환경당 여러 리소소 그룹을 정의할 수 있습니다. 예를 들어, 물리적 장치로 배포할 때 여러 물리적 장치가 있을 수 있습니다. 각 장치는 배포 대상이 될 수 있지만, 한 번에 한 장치당 한 번의 배포만 발생할 수 있습니다.
키워드 유형: 잡 키워드. 잡의 일부로만 사용할 수 있습니다.
가능한 입력값:
- 문자, 숫자,
-
,_
,/
,$
,{
,}
,.
, 및 공백만 포함할 수 있습니다. 시작이나 끝을/
로 시작할 수 없습니다. CI/CD 변수는 지원됩니다.
resource_group
의 예시:
production으로-배포:
script: deploy
resource_group: production
이 예에서 두 개의 production으로-배포
작업은 각각 별도의 파이프라인에서 동시에 실행될 수 없습니다. 결과적으로 동시 배포가 절대로 프로덕션 환경에서 발생하지 않도록 보장할 수 있습니다.
관련 주제:
retry
retry
를 사용하여 작업이 실패할 경우 재시도되는 횟수를 구성하세요.
정의되지 않으면 기본값은 0
이며 작업은 재시도되지 않습니다.
작업이 실패하면 해당 작업은 성공 또는 최대 재시도 횟수에 도달할 때까지 2회 더 처리됩니다.
기본적으로 모든 실패 유형은 작업을 재시도하게 합니다. retry:when
또는 retry:exit_codes
을 사용하여 어떤 실패를 재시도할지 선택하세요.
Keyword type: Job keyword. 작업 또는 default
섹션 일부로만 사용할 수 있습니다.
가능한 입력값:
-
0
(기본값),1
, 또는2
.
retry
의 예시:
test:
script: rspec
retry: 2
test_advanced:
script:
- echo "종료 코드가 137인 스크립트 실행."
- exit 137
retry:
max: 2
when: runner_system_failure
exit_codes: 137
test_advanced
는 종료 코드가 137
이거나 실행중인 시스템에 장애가 발생할 경우 최대 2회까지 재시도됩니다.
retry:when
retry:when
을 retry:max
와 함께 사용하여 특정 실패 사례에 대해 작업을 재시도하세요.
retry:max
는 retry
와 같이 최대 재시도 횟수이며 0
, 1
, 또는 2
가 될 수 있습니다.
Keyword type: Job keyword. 작업 또는 default
섹션 일부로만 사용할 수 있습니다.
가능한 입력값:
- 단일 실패 유형 또는 하나 이상의 실패 유형 배열:
-
always
: 모든 실패시 재시도 (기본값). -
unknown_failure
: 실패 이유가 알려지지 않았을 때 재시도. -
script_failure
: 다음 경우에 재시도:- 스크립트 실행 실패시
- 러너가 Docker 이미지를 가져오지 못했을 때.
docker
,docker+machine
,kubernetes
executors.
-
api_failure
: API 실패시 재시도. -
stuck_or_timeout_failure
: 작업이 멈추거나 시간이 초과되었을 때 재시도. -
runner_system_failure
: 러너 시스템 장애시 재시도 (예: 작업 설정 실패). -
runner_unsupported
: 러너가 지원되지 않을 경우 재시도. -
stale_schedule
: 지연된 작업을 실행할 수 없을 경우 재시도. -
job_execution_timeout
: 작업에 설정된 최대 실행 시간을 초과했을 때 재시도. -
archived_failure
: 작업이 보관되어 실행할 수 없을 경우 재시도. -
unmet_prerequisites
: 작업이 선행 작업을 완료하지 못했을 때 재시도. -
scheduler_failure
: 스케줄러가 작업을 러너에 할당하지 못했을 때 재시도. -
data_integrity_failure
: 알 수 없는 작업 문제가 있을 경우 재시도.
retry:when
의 예시 (단일 실패 유형):
test:
script: rspec
retry:
max: 2
when: runner_system_failure
러너 시스템 장애가 아닌 경우에는 작업이 재시도되지 않습니다.
retry:when
의 예시 (여러 실패 유형 배열):
test:
script: rspec
retry:
max: 2
when:
- runner_system_failure
- stuck_or_timeout_failure
retry:exit_codes
- GitLab 16.10에서 도입됨 플래그
ci_retry_on_exit_codes
와 함께. 기본적으로 비활성화.
플래그:
자체 호스팅 GitLab에서는 기본적으로 이 기능을 사용할 수 없습니다. 사용하려면 관리자가 플래그 활성화할 수 있습니다. ci_retry_on_exit_codes
라는 플래그를 사용하세요.
retry:exit_codes
를 retry:max
와 함께 사용하여 특정 실패 사례에 대해 작업을 재시도하세요.
retry:max
는 retry
와 같이 최대 재시도 횟수이며 0
, 1
, 또는 2
가 될 수 있습니다.
Keyword type: Job keyword. 작업 또는 default
섹션 일부로만 사용할 수 있습니다.
가능한 입력값:
- 단일 종료 코드.
- 종료 코드 배열.
retry:exit_codes
의 예시:
test_job_1:
script:
- echo "종료 코드가 1인 스크립트 실행. 이 작업은 재시도되지 않습니다."
- exit 1
retry:
max: 2
exit_codes: 137
test_job_2:
script:
- echo "종료 코드가 137인 스크립트 실행. 이 작업은 재시도될 것입니다."
- exit 137
retry:
max: 1
exit_codes:
- 255
- 137
관련 주제:
변수를 사용하여 작업 실행의 특정 단계에 대한 재시도 시도 횟수를 지정할 수 있습니다.
rules
- GitLab 12.3에서 소개되었습니다.
rules
를 사용하여 파이프라인에서 작업을 포함하거나 제외합니다.
rules
는 파이프라인이 생성될 때 평가되며, 평가는 순서대로 진행됩니다. 일치하는 항목이 발견되면, 작업은 구성에 따라 파이프라인에 포함되거나 제외됩니다.
작업 스크립트에서 생성된 dotenv 변수를 rules
에서 사용할 수 없습니다. 이는 rules
가 작업 실행 전에 평가되기 때문입니다.
rules
는 only/except
를 대체하고, 동일한 작업에서 함께 사용할 수 없습니다. 한 작업에서 두 키워드를 구성하면 GitLab에서 key may not be used with rules
오류가 반환됩니다.
rules
는 다음과 같이 정의된 규칙 배열을 허용합니다:
if
changes
exists
allow_failure
variables
when
여러 키워드를 함께 결합하여 복잡한 규칙을 만들 수 있습니다.
작업은 파이프라인에 추가됩니다:
-
if
,changes
, 또는exists
규칙이 일치하고, 또한when: on_success
(기본값),when: delayed
, 또는when: always
를 갖는 경우. - 특정
when: on_success
,when: delayed
, 또는when: always
에 도달한 경우.
작업은 파이프라인에 추가되지 않습니다:
- 규칙이 일치하지 않는 경우.
- 규칙이 일치하고
when: never
를 갖는 경우.
!참조
태그를 사용하여 서로 다른 작업에서 규칙 구성 재사용을 할 수 있습니다.
rules:if
rules:if
절을 사용하여 작업을 파이프라인에 추가할 시기를 지정합니다:
-
if
문이 true이면, 작업이 파이프라인에 추가됩니다. -
if
문이 true이지만when: never
와 결합된 경우, 작업이 파이프라인에 추가되지 않습니다. - 어떤
if
문도 true가 아닌 경우, 작업이 파이프라인에 추가되지 않습니다.
if
절은 CI/CD 변수 또는 사전 정의된 CI/CD 변수의 값에 따라 평가됩니다.
일부 예외가 있습니다.
키워드 유형: 작업별 및 파이프라인별. 작업의 동작을 구성하기 위해 작업 부분으로 사용하거나, workflow
와 함께 사용하여 파이프라인 동작을 구성할 수 있습니다.
가능한 입력:
rules:if
의 예시:
job:
script: echo "안녕, Rules!"
rules:
- if: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^feature/ && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME != $CI_DEFAULT_BRANCH
when: never
- if: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^feature/
when: manual
allow_failure: true
- if: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME
추가 세부 정보:
- 규칙이 일치하고 정의된
when
이 없는 경우, 규칙은 작업에 대해 정의된 기본값이on_success
인when
을 사용합니다. - GitLab 14.5 이전에는 규칙 당
when
을 한 번 정의하거나 작업 수준에서 한 번 정의할 수 있었습니다. 이는 모든 규칙에 적용되는 것입니다. 작업 수준의when
과 규칙 내의when
을 혼합할 수 없습니다. - GitLab 14.6 이후에는 작업 수준의
when
과 규칙 내의when
을 혼합할 수 있습니다.rules
의when
구성이 작업 수준의when
을 우선합니다. -
script
섹션의 변수와 달리, 규칙 표현식의 변수는 항상$VARIABLE
형식으로 작성됩니다.-
rules:if
와include
를 함께 사용하여 조건부로 다른 구성 파일을 포함할 수 있습니다.
-
-
=~
및!~
표현식의 오른쪽에 있는 CI/CD 변수는 정규 표현식으로 평가됩니다.
관련 주제:
-
rules
를 위한 일반적인if
표현식. - 중복 파이프라인 피하기.
-
병합 요청 파이프라인 실행에
rules
사용하기.
rules:changes
rules:changes
을 사용하여 특정 파일의 변경 사항을 확인하여 파이프라인에 작업을 추가할 때 지정합니다.
경고:
rules: changes
는 브랜치 파이프라인 또는 병합 요청 파이프라인에서만 사용해야합니다. 다른 파이프라인 유형에서도 rules: changes
를 사용할 수 있지만, rules: changes
는 항상 새로운 브랜치 파이프라인이거나 Git push
이벤트가 없는 경우에는 항상 참으로 평가됩니다. 태그 파이프라인, 예약된 파이프라인 및 수동 파이프라인과 같은 파이프라인은 Git push
이벤트가 연결되어 있지 않습니다. 이러한 경우에는 비교할 브랜치를 지정하기 위해 rules: changes: compare_to
를 사용하십시오.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.
가능한 입력:
특정 수의 포함된 배열:
- 파일의 경로. GitLab 13.6 이상에서는 변수를 포함한 파일 경로를 포함할 수 있습니다.
파일 경로 배열은 또한 rules:changes:paths
에 있을 수 있습니다.
- 다음을 위한 와일드카드 경로:
- 단일 디렉토리에 대한 경로, 예를 들어 path/to/directory/*
.
- 디렉토리와 해당 하위 디렉토리에 대한 와일드카드 경로, 예를 들어 path/to/directory/**/*
.
- 동일한 확장자 또는 여러 확장자를 가진 모든 파일을 위한 와일드카드 glob 경로, 예를 들어 *.md
또는 path/to/directory/*.{rb,py,sh}
.
- 루트 디렉토리의 파일이나 모든 디렉토리에 대한 와일드카드 경로는 이중 인용 부호로 묶여 있습니다. 예를 들어 "*.json"
또는 "**/*.json"
.
rules:changes
의 예시:
docker build:
script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
changes:
- Dockerfile
when: manual
allow_failure: true
- 파이프라인이 병합 요청 파이프라인인 경우
Dockerfile
을 변경 사항을 확인하십시오. -
Dockerfile
에 변경 사항이 있으면 작업을 수동 작업으로 파이프라인에 추가하고, 작업이 트리거되지 않아도 파이프라인이 계속 실행됩니다 (allow_failure: true
). -
rules: changes
섹션 당 최대 50개의 패턴 또는 파일 경로를 정의할 수 있습니다. -
Dockerfile
에 변경 사항이 없으면 어떤 파이프라인에도 작업을 추가하지 마십시오 (when: never
와 동일함). -
rules:changes:paths
는 하위 키가 없는rules: changes
와 동일합니다.
추가 세부 정보:
- rules: changes
는 only: changes
및 except: changes
와 동일한 방식으로 작동합니다.
- Glob 패턴은 Ruby의 File.fnmatch
및 flags의 해석과 함께 구현됩니다.
- except:changes
와 비슷한 규칙을 구현하려면 when: never
를 사용할 수 있습니다.
- changes
는 일치하는 파일 중 하나라도 변경되었을 때 true
로 해결됩니다(OR
연산).
관련 주제:
- rules: changes
을 사용할 때 작업이 또는 파이프라인이 예상치 않게 실행될 수 있습니다.
rules:changes:paths
rules:changes
를 사용하여 특정 파일이 변경될 때만 작업이 파이프라인에 추가되도록 지정하고, rules:changes:paths
를 사용하여 파일을 지정합니다.
rules:changes:paths
는 하위 키가 없는 rules:changes
를 사용하는 것과 동일합니다. 모든 추가 세부 정보와 관련 주제는 동일합니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.
가능한 입력: - 파일 경로의 배열. 파일 경로에 변수를 포함시킬 수 있습니다.
rules:changes:paths
의 예시:
docker-build-1:
script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
changes:
- Dockerfile
docker-build-2:
script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
changes:
paths:
- Dockerfile
이 예시에서 두 작업은 동일한 동작을 합니다.
rules:changes:compare_to
-
15.3에서 도입되었습니다. 기본적으로 사용 가능한
ci_rules_changes_compare
플래그와 함께. -
15.5에서 일반적으로 사용 가능하며
ci_rules_changes_compare
플래그가 제거되었습니다.
rules:changes:compare_to
를 사용하여 rules:changes:paths
에 나열된 파일의 변경 사항을 비교할 대상 ref를 지정합니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있으며 rules:changes:paths
와 함께 사용되어야 합니다.
가능한 입력:
-
main
,branch1
, 또는refs/heads/branch1
과 같은 브랜치 이름. -
tag1
또는refs/tags/tag1
과 같은 태그 이름. -
2fg31ga14b
와 같은 커밋 SHA.
rules:changes:compare_to
의 예시:
docker build:
script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
rules:
- if: $CI_PIPELINE_SOURCE == "merge_request_event"
changes:
paths:
- Dockerfile
compare_to: 'refs/heads/branch1'
이 예에서 docker build
작업은 Dockerfile
이 refs/heads/branch1
을 기준으로 변경되었고 파이프라인 소스가 병합 요청 이벤트인 경우에만 포함됩니다.
rules:exists
exists
를 사용하여 저장소에 특정 파일이 존재할 때 작업을 실행합니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.
가능한 입력:
- 파일 경로 배열. 경로는 프로젝트 디렉토리(
$CI_PROJECT_DIR
)를 기준으로 상대적이며 직접 외부로 연결할 수 없습니다. 파일 경로에는 glob 패턴과 CI/CD 변수를 사용할 수 있습니다.
rules:exists
의 예시:
job:
script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
rules:
- exists:
- Dockerfile
Dockerfile
이 저장소 어디에 있든, job
은 실행됩니다.
추가 세부 정보:
- glob 패턴은 Ruby의
File.fnmatch
와 함께 flags를 사용하여 해석됩니다(File::FNM_PATHNAME | File::FNM_DOTMATCH | File::FNM_EXTGLOB
). - 성능상의 이유로, GitLab은
exists
패턴 또는 파일 경로에 대해 최대 10,000번의 확인을 수행합니다. 10,000번째 확인 이후에는 패턴화된 glob은 항상 일치합니다. 다시 말해,exists
규칙은 항상 일치한다고 가정합니다. 이는 10,000개 이상의 파일이 있는 프로젝트이거나exists
규칙이 10,000번 이상 확인된 경우에도 동일합니다. -
rules:exists
섹션 당 최대 50개의 패턴 또는 파일 경로를 정의할 수 있습니다. -
exists
는 나열된 파일 중 하나라도 발견되면true
로 해석됩니다(OR
연산).
rules:allow_failure
- 12.8에서 도입되었습니다.
rules
에서 allow_failure: true
를 사용하여 작업이 실패해도 파이프라인을 중지시키지 않도록 허용합니다.
수동 작업에도 allow_failure: true
를 사용할 수 있습니다. 파이프라인은 수동 작업의 결과를 기다리지 않고 계속 실행됩니다. 규칙에 따른 allow_failure: false
는 수동 작업이 실행될 때까지 파이프라인을 기다리게 합니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.
가능한 입력:
-
true
또는false
. 정의되지 않은 경우 기본값은false
입니다.
rules:allow_failure
의 예시:
job:
script: echo "Hello, Rules!"
rules:
- if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == $CI_DEFAULT_BRANCH
when: manual
allow_failure: true
규칙이 일치하는 경우, 작업은 allow_failure: true
를 가진 수동 작업입니다.
추가 세부 정보:
- 규칙 수준의
rules:allow_failure
는 작업 수준의allow_failure
를 재정의하며, 특정 규칙이 작업을 트리거할 때만 적용됩니다.
rules:needs
- GitLab 16.0에서
introduce_rules_with_needs
이라는 플래그로 소개되었습니다. 기본적으로 비활성화됩니다.- GitLab 16.2에서 일반적으로 사용할 수 있게 되었습니다. 기능 플래그
introduce_rules_with_needs
가 제거되었습니다.
needs
를 사용하여 규칙에서 작업의 needs
를 조건에 따라 업데이트합니다. 조건이 규칙과 일치하는 경우 작업의 needs
구성은 규칙의 needs
로 완전히 대체됩니다.
키워드 유형: 작업별. 작업의 일부로만 사용할 수 있습니다.
가능한 입력:
- 문자열로 된 작업 이름의 배열.
- 작업 이름과 선택적으로 추가 속성이 포함된 해시.
- 특정 조건을 충족하는 경우 작업 needs를 없음으로 설정하려면 빈 배열(
[]
)을 사용합니다.
rules:needs
예시:
build-dev:
stage: build
rules:
- if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH
script: echo "기능 브랜치이므로 개발 버전 빌드 중..."
build-prod:
stage: build
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
script: echo "기본 브랜치이므로 프로덕션 버전 빌드 중..."
specs:
stage: test
needs: ['build-dev']
rules:
- if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
needs: ['build-prod']
- when: on_success # 다른 경우에도 작업 실행
script: echo "기본적으로 개발 사양 실행 또는 기본 브랜치일 때 프로덕션 사양 실행..."
이 예시에서:
- 파이프라인이 기본 브랜치가 아닌 브랜치에서 실행되면
specs
작업은build-dev
작업이 필요합니다(기본 동작). - 파이프라인이 기본 브랜치에서 실행되고 따라서 규칙이 조건에 일치하면
specs
작업은 대신에build-prod
작업이 필요합니다.
추가 세부 정보:
- 규칙의
needs
는 작업 수준에서 정의된needs
를 재정의합니다. 재정의된 경우 동작은 작업 수준needs
과 동일합니다. - 규칙의
needs
는artifacts
및optional
을 허용합니다.
rules:variables
- GitLab 13.7에서 도입되었습니다.
- 기능 플래그가 제거된 GitLab 13.10에서.
rules
에서 variables
을 사용하여 특정 조건에 대한 변수를 정의합니다.
키워드 유형: 작업별. 작업의 일부로만 사용할 수 있습니다.
가능한 입력:
-
VARIABLE-NAME: 값을
형식으로 된 변수 해시.
rules:variables
예시:
job:
variables:
DEPLOY_VARIABLE: "default-deploy"
rules:
- if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
variables: # 작업 수준에서 정의된 DEPLOY_VARIABLE을 재정의
DEPLOY_VARIABLE: "deploy-production" #합니다.
- if: $CI_COMMIT_REF_NAME =~ /feature/
variables:
IS_A_FEATURE: "true" # 새 변수를 정의합니다.
script:
- echo "$DEPLOY_VARIABLE을(를) 인자로 사용하여 스크립트 실행"
- "$IS_A_FEATURE가 있는 경우 다른 스크립트 실행"
rules:interruptible
- GitLab 16.10에서 도입되었습니다.
interruptible
를 사용하여 규칙에서 특정 조건에 대한 작업의 interruptible
값을 업데이트합니다.
키워드 유형: 작업별. 작업의 일부로만 사용할 수 있습니다.
가능한 입력:
-
true
또는false
.
rules:interruptible
예시:
job:
script: echo "안녕, 규칙!"
interruptible: true
rules:
- if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
interruptible: false # 작업 수준에서 정의된 interruptible을 재정의합니다.
- when: on_success
추가 세부 정보:
- 규칙 수준의
rules:interruptible
은 작업 수준의interruptible
을 재정의하며 특정 규칙이 작업을 트리거할 때만 적용됩니다.
script
script
를 사용하여 실행기가 실행할 명령을 지정합니다.
트리거 작업을 제외한 모든 작업이 script
키워드가 필요합니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.
가능한 입력: 다음을 포함하는 배열:
- 단일 라인 명령.
- 여러 줄로 나누어진 긴 명령.
- YAML 앵커.
CI/CD 변수는 지원됩니다.
script
예시:
job1:
script: "bundle exec rspec"
job2:
script:
- uname -a
- bundle exec rspec
추가 세부 정보:
-
script
에서 특수 문자를 사용할 때, 작은 따옴표('
) 또는 큰 따옴표("
)를 사용해야 합니다.
관련 주제:
- 0이 아닌 종료 코드 무시.
-
색상 코드와 함께
script
사용하여 작업 로그를 쉽게 검토할 수 있습니다. - 사용자 정의 접기 가능한 섹션 만들기로 작업 로그 출력을 단순화할 수 있습니다.
비밀
- GitLab 13.4에서 도입되었습니다.
CI/CD 비밀을 지정하여 다음과 같은 작업을 수행합니다.
secrets:vault
- GitLab 13.4 및 GitLab Runner 13.4에서 도입되었습니다.
secrets:vault
를 사용하여 HashiCorp Vault에서 제공하는 비밀을 지정합니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.
가능한 입력값:
-
engine:name
: 비밀 엔진의 이름. -
engine:path
: 비밀 엔진의 경로. -
path
: 비밀의 경로. -
field
: 암호가 저장된 필드의 이름.
secrets:vault
예시:
모든 세부 정보를 명시적으로 지정하고 KV-V2 비밀 엔진을 사용하는 경우:
job:
secrets:
DATABASE_PASSWORD: # 이 CI/CD 변수에 비밀의 경로 저장
vault: # 비밀은 `ops/data/production/db`, 필드는 `password`로 전환
engine:
name: kv-v2
path: ops
path: production/db
field: password
이 구문을 간략하게 작성할 수 있습니다. 간략한 구문에서 engine:name
및 engine:path
모두 기본적으로 kv-v2
로 설정됩니다:
job:
secrets:
DATABASE_PASSWORD: # 이 CI/CD 변수에 비밀의 경로 저장
vault: production/db/password # 비밀은 `kv-v2/data/production/db`, 필드는 `password`로 전환
간단한 구문에서 사용자 정의 비밀 엔진 경로를 지정하려면, @
로 시작하는 접미사를 추가하세요:
job:
secrets:
DATABASE_PASSWORD: # 이 CI/CD 변수에 비밀의 경로 저장
vault: production/db/password@ops # 비밀은 `ops/data/production/db`, 필드는 `password`로 전환
secrets:gcp_secret_manager
- GitLab 16.8 및 GitLab Runner 16.8에서 도입되었습니다.
secrets:gcp_secret_manager
를 사용하여 GCP Secret Manager에서 제공하는 비밀을 지정합니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.
가능한 입력값:
-
name
: 비밀의 이름. -
version
: 비밀의 버전.
secrets:gcp_secret_manager
예시:
job:
secrets:
DATABASE_PASSWORD:
gcp_secret_manager:
name: 'test'
version: 2
관련 주제:
secrets:azure_key_vault
- GitLab 16.3 및 GitLab Runner 16.3에서 도입되었습니다.
secrets:azure_key_vault
를 사용하여 Azure Key Vault에서 제공하는 비밀을 지정합니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.
가능한 입력값:
-
name
: 비밀의 이름. -
version
: 비밀의 버전.
secrets:azure_key_vault
예시:
job:
secrets:
DATABASE_PASSWORD:
azure_key_vault:
name: 'test'
version: 'test'
관련 주제:
secrets:file
- GitLab 14.1 및 GitLab Runner 14.1에서 도입되었습니다.
secrets:file
을 사용하여 비밀을 file
또는 variable
유형 CI/CD 변수로 구성합니다.
기본적으로, 비밀은 file
유형 CI/CD 변수로 작업에 전달됩니다. 값
은 파일에 저장되며, 변수에는 파일의 경로가 포함됩니다.
소프트웨어가 file
유형 CI/CD 변수를 사용할 수 없는 경우, file: false
를 설정하여
값을 직접 변수에 저장할 수 있습니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.
가능한 입력값:
-
true
(기본값) 또는false
.
secrets:file
예시:
job:
secrets:
DATABASE_PASSWORD:
vault: production/db/password@ops
file: false
추가 세부 정보:
-
file
키워드는 CI/CD 변수의 설정이며,vault
섹션이 아닌 CI/CD 변수 이름 아래에 중첩되어야 합니다.
secrets:token
- GitLab 15.8에서 도입되었으며, Limit JSON Web Token (JWT) access 설정으로 제어됩니다.
- GitLab 16.0에선 항상 사용 가능하고 Limit JSON Web Token (JWT) access 설정은 제거되었습니다.
secrets:token
을 사용하여 Vault와 인증할 때 토큰의 CI/CD 변수를 참조하여 명시적으로 사용할 토큰을 선택합니다.
키워드 유형: Job 키워드. Job의 일부로만 사용할 수 있습니다.
가능한 입력:
- ID 토큰의 이름
secrets:token
의 예시:
job:
id_tokens:
AWS_TOKEN:
aud: https://aws.example.com
VAULT_TOKEN:
aud: https://vault.example.com
secrets:
DB_PASSWORD:
vault: gitlab/production/db
token: $VAULT_TOKEN
추가 정보:
-
token
키워드가 설정되지 않은 경우, 첫 번째 ID 토큰이 사용됩니다.
services
services
는 스크립트 실행에 필요한 추가 Docker 이미지를 지정하는 데 사용합니다. services
이미지는 image
키워드에서 지정된 이미지에 연결됩니다.
키워드 유형: Job 키워드. Job의 일부 또는 default
섹션에서만 사용할 수 있습니다.
가능한 입력: 이러한 형식 중 하나로, 레지스트리 경로를 포함할 수 있는 서비스 이미지의 이름입니다.
CI/CD 변수는 지원됩니다만 alias
에 대해서는 지원되지 않습니다.
services
의 예시:
default:
image:
name: ruby:2.6
entrypoint: ["/bin/bash"]
services:
- name: my-postgres:11.7
alias: db-postgres
entrypoint: ["/usr/local/bin/db-postgres"]
command: ["start"]
before_script:
- bundle install
test:
script:
- bundle exec rake spec
이 예시에서 GitLab은 작업을 위해 두 개의 컨테이너를 시작합니다:
- 스크립트 명령을 실행하는 Ruby 컨테이너
- PostgreSQL 컨테이너. Ruby 컨테이너의 스크립트 명령은
db-postgres
호스트 이름의 PostgreSQL 데이터베이스에 연결할 수 있습니다.
관련 주제:
-
services
에 대한 사용 가능한 설정. -
.gitlab-ci.yml
파일에서services
정의. - Docker 컨테이너에서 CI/CD 작업 실행.
- Docker를 사용하여 Docker 이미지 빌드.
services:docker
services:docker
를 사용하여 GitLab Runner의 Docker 실행기에 옵션을 전달합니다.
키워드 유형: Job 키워드. Job의 일부 또는 default
섹션에서만 사용할 수 있습니다.
가능한 입력:
Docker 실행기의 옵션 해시로, 다음을 포함할 수 있습니다:
-
platform
: 이미지를 가져올 아키텍처를 선택합니다. 지정되지 않은 경우, 기본값은 호스트 Runner와 동일한 플랫폼입니다. -
user
: 컨테이너를 실행할 때 사용할 사용자 이름 또는 UID를 지정합니다.
services:docker
의 예시:
arm-sql-job:
script: echo "service 컨테이너에서 sql 테스트 실행"
image: ruby:2.6
services:
- name: super/sql:experimental
docker:
platform: arm64/v8
user: dave
추가 정보:
-
services:docker:platform
은docker pull --platform
옵션에 매핑됩니다. -
services:docker:user
은docker run --user
옵션에 매핑됩니다.
services:pull_policy
GitLab Runner가 Docker 이미지를 가져오는 데 사용하는 풀 정책입니다.
키워드 유형: Job 키워드. Job의 일부 또는 default
섹션에서만 사용할 수 있습니다.
가능한 입력:
- 단일 풀 정책 또는 배열 내의 여러 풀 정책입니다.
always
,if-not-present
, 또는never
일 수 있습니다.
services:pull_policy
의 예시:
job1:
script: echo "단일 풀 정책."
services:
- name: postgres:11.6
pull_policy: if-not-present
job2:
script: echo "여러 풀 정책."
services:
- name: postgres:11.6
pull_policy: [always, if-not-present]
추가 정보:
- Runner가 정의된 풀 정책을 지원하지 않는 경우, 작업은
ERROR: Job failed
와 같은 오류로 실패합니다.the configured PullPolicies ([always]) are not allowed by AllowedPullPolicies ([never])
.
관련 주제:
stage
stage
은 작업이 실행되는 단계를 정의하는 데 사용됩니다. 동일한 stage
내의 작업은 병렬로 실행될 수 있습니다(자세한 내용은 추가 세부 정보를 참조).
stage
가 정의되지 않았다면, 작업은 기본적으로 test
단계를 사용합니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.
가능한 입력: 문자열로, 다음 중 하나일 수 있습니다:
- 기본 단계.
- 사용자 정의 단계.
stage
예시:
stages:
- build
- test
- deploy
job1:
stage: build
script:
- echo "이 작업은 코드를 컴파일합니다."
job2:
stage: test
script:
- echo "이 작업은 컴파일된 코드를 테스트합니다. 빌드 단계가 완료되면 실행됩니다."
job3:
script:
- echo "이 작업도 테스트 단계에서 실행됩니다."
job4:
stage: deploy
script:
- echo "이 작업은 코드를 배포합니다. 테스트 단계가 완료되면 실행됩니다."
environment: production
추가 세부 정보:
- 작업은 서로 다른 러너에서 실행되는 경우 병렬로 실행될 수 있습니다.
- 러너가 하나뿐이라면, 러너의
concurrent
설정이1
보다 크면 작업을 병렬로 실행할 수 있습니다.
stage: .pre
- GitLab 12.4에서 도입.
.pre
단계를 사용하여 작업을 파이프라인의 시작에서 실행하도록 설정합니다. .pre
는 항상 파이프라인의 첫 번째 단계입니다. 사용자 정의 단계는 .pre
이후에 실행됩니다. stages
에서 .pre
을 정의할 필요는 없습니다.
파이프라인에 .pre
또는 .post
단계의 작업만 포함된 경우 파이프라인이 실행되지 않습니다. 다른 단계에 적어도 한 개의 다른 작업이 있어야 합니다.
키워드 유형: 작업의 stage
키워드와 함께만 사용할 수 있습니다.
stage: .pre
예시:
stages:
- build
- test
job1:
stage: build
script:
- echo "이 작업은 빌드 단계에서 실행됩니다."
first-job:
stage: .pre
script:
- echo ".pre 단계에서 이 작업이 실행됩니다. 다른 모든 단계보다 먼저 실행됩니다."
job2:
stage: test
script:
- echo "이 작업은 테스트 단계에서 실행됩니다."
stage: .post
- GitLab 12.4에서 도입.
.post
단계를 사용하여 작업을 파이프라인의 끝에서 실행하도록 설정합니다. .post
는 항상 파이프라인의 마지막 단계입니다. 사용자 정의 단계는 .post
이전에 실행됩니다. stages
에서 .post
을 정의할 필요는 없습니다.
파이프라인에 .pre
또는 .post
단계의 작업만 포함된 경우 파이프라인이 실행되지 않습니다. 다른 단계에 적어도 한 개의 다른 작업이 있어야 합니다.
키워드 유형: 작업의 stage
키워드와 함께만 사용할 수 있습니다.
stage: .post
예시:
stages:
- build
- test
job1:
stage: build
script:
- echo "이 작업은 빌드 단계에서 실행됩니다."
last-job:
stage: .post
script:
- echo "이 작업은 .post 단계에서 실행됩니다. 다른 모든 단계보다 나중에 실행됩니다."
job2:
stage: test
script:
- echo "이 작업은 테스트 단계에서 실행됩니다."
추가 세부 정보:
- 파이프라인에
needs: []
작업 및.pre
단계 작업이 포함되어 있는 경우, 파이프라인이 생성되자마자 모든 작업이 시작됩니다.needs: []
로 시작하는 작업은 단계 구성을 무시하고 즉시 시작됩니다.
tags
- GitLab 14.3에서 GitLab.com에서 작업당 최대 50개 태그 제한이 활성화됨.
- GitLab 14.3에서 자체 호스트형에서 작업당 최대 50개 태그 제한이 활성화됨.
tags
는 프로젝트에서 사용 가능한 모든 러너 목록에서 특정 러너를 선택하는 데 사용됩니다.
러너를 등록할 때 러너의 태그를 지정할 수 있습니다. 예를 들어 ruby
, postgres
, 또는 development
등입니다. 작업을 가져와 실행하려면 작업에 나열된 모든 태그가 할당된 러너여야 합니다.
키워드 유형: 작업 키워드. 작업 또는 default
섹션의 일부로만 사용할 수 있습니다.
가능한 입력:
- 태그 이름의 배열.
- CI/CD 변수는 GitLab 14.1 이상에서 지원됨.
tags
예시:
job:
tags:
- ruby
- postgres
이 예에서 ruby
와 postgres
두 가지 태그가 모두 있는 러너만 작업을 실행할 수 있습니다.
추가 세부 정보:
-
GitLab 14.3 이상에서는 태그 수가
50
보다 작아야 합니다.
관련 주제:
timeout
- GitLab 12.3에서 나왔습니다.
특정 작업에 대한 타임아웃을 구성하기 위해 timeout
을 사용합니다. 작업이 타임아웃보다 오래 실행되면 작업이 실패합니다.
작업 수준의 타임아웃은 프로젝트 수준의 타임아웃보다 길 수 있지만 런너의 타임아웃보다 길 수는 없습니다.
Keyword type: Job keyword. 작업 또는 default
section의 일부로만 사용할 수 있습니다.
가능한 입력: 자연어로 작성된 기간. 예를 들어, 다음은 모두 동등합니다:
3600 seconds
60 minutes
one hour
timeout
예시:
build:
script: build.sh
timeout: 3시간 30분
test:
script: rspec
timeout: 3h 30m
trigger
- GitLab 13.9에서
resource_group
지원이 추가되었습니다.- GitLab 16.4에서
environment
지원이 추가되었습니다.
trigger
을 사용하여 작업이 “트리거 작업”임을 선언하고, 이는 다음 중 하나인 다운스트림 파이프라인을 시작합니다:
트리거 작업은 제한된 GitLab CI/CD 구성 키워드만 사용할 수 있습니다. 트리거 작업에서 사용할 수 있는 키워드는 다음과 같습니다:
-
allow_failure
. -
extends
. -
needs
, 단,needs:project
은 사용할 수 없습니다. -
only
및except
. -
rules
. -
stage
. -
trigger
. -
variables
. -
when
(값으로on_success
,on_failure
, 또는always
만 사용). -
resource_group
. -
environment
.
Keyword type: Job keyword. 작업의 일부로만 사용할 수 있습니다.
가능한 입력:
- 멀티 프로젝트 파이프라인의 경우, 다운스트림 프로젝트의 경로. CI/CD 변수는 GitLab 15.3 이후로 지원됩니다만, 작업 레벨의 지속 변수은 지원하지 않습니다. 또는
trigger:project
를 사용하세요. - 자식 파이프라인의 경우,
trigger:include
를 사용하세요.
trigger
예시:
trigger-multi-project-pipeline:
trigger: my-group/my-project
추가 세부 정보:
- 수동 트리거 작업을 시작하기 위해 API를 사용할 수 없습니다.
-
GitLab 13.5 및 이후에서
trigger
와 함께when:manual
을 사용할 수 있습니다. GitLab 13.4 및 이전에서 함께 사용하면jobs:#{job-name} when should be on_success, on_failure or always
오류가 발생합니다. - 수동 트리거 작업을 실행하기 전에 CI/CD 변수를 수동으로 지정할 수 없습니다.
- 수동 파이프라인 변수 및 예약 파이프라인 변수은 기본적으로 다운스트림 파이프라인에 전달되지 않습니다. trigger:forward를 사용하여 이러한 변수를 다운스트림 파이프라인에 전달하세요.
- 작업 레벨의 지속 변수는 트리거 작업에서 사용할 수 없습니다.
- 러너의
config.toml
에 정의된 환경 변수는 트리거 작업에서 사용할 수 없으며, 다운스트림 파이프라인으로 전달되지 않습니다.
관련 주제:
- 멀티 프로젝트 파이프라인 구성 예시.
- 특정 브랜치, 태그 또는 커밋에 대한 파이프라인을 실행하려면 트리거 토큰을 사용하여 파이프라인 트리거 API에 인증하세요. 트리거 토큰은
trigger
키워드와 다릅니다.
trigger:include
trigger:include
를 사용하여 작업이 “트리거 작업”이라고 선언하고,
하위 파이프라인을 시작하는 데 사용합니다.
trigger:include:artifact
를 사용하여 동적 하위 파이프라인을 트리거합니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.
가능한 입력값:
- 하위 파이프라인 구성 파일의 경로.
trigger:include
의 예시:
trigger-child-pipeline:
trigger:
include: path/to/child-pipeline.gitlab-ci.yml
관련 주제:
trigger:project
trigger:project
를 사용하여 작업이 “트리거 작업”이라고 선언하고,
다중 프로젝트 파이프라인을 시작하는 데 사용합니다.
기본적으로, 다중 프로젝트 파이프라인은 기본 브랜치를 대상으로 트리거합니다.
다른 브랜치를 지정하려면 trigger:branch
를 사용하세요.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.
가능한 입력값:
- 하위 프로젝트의 경로. GitLab 15.3부터는 CI/CD 변수가 지원됩니다, 그러나 작업 수준의 지속 변수는 지원되지 않습니다.
trigger:project
의 예시:
trigger-multi-project-pipeline:
trigger:
project: my-group/my-project
다른 브랜치용 trigger:project
의 예시:
trigger-multi-project-pipeline:
trigger:
project: my-group/my-project
branch: development
관련 주제:
- 다중 프로젝트 파이프라인 구성 예시.
- 특정 브랜치, 태그 또는 커밋에 대한 파이프라인 실행을 위해 트리거 토큰을 사용할 수도 있으며,
파이프라인 트리거 API와 인증하기 위해 트리거 토큰을 사용합니다.
트리거 토큰은
trigger
키워드와는 다릅니다.
trigger:strategy
trigger:strategy
를 사용하여 trigger
작업이 다운스트림 파이프라인이 완료될 때까지
성공으로 표시되기 전까지 기다리도록 강제할 수 있습니다.
기본 동작과 다른 점은 trigger
작업이 완료되자마자 성공으로 표시되는 것이 아니라는 것입니다.
이 설정은 파이프라인 실행을 병렬이 아닌 선형으로 만듭니다.
trigger:strategy
의 예시:
trigger_job:
trigger:
include: path/to/child-pipeline.yml
strategy: depend
이 예시에서, 다음 스테이지의 작업들은 트리거된 파이프라인이 성공적으로 완료될 때까지 기다립니다.
추가 세부 정보:
- 다운스트림 파이프라인의 옵션 수동 작업은 다운스트림 파이프라인 또는 상위 트리거 작업의 상태에 영향을 미치지 않습니다. 선택적인 수동 작업 없이도 다운스트림 파이프라인은 성공적으로 완료될 수 있습니다.
- 다운스트림 파이프라인의 차단 수동 작업이 수동 작업으로 인해 대기 상태인 경우, 트리거 작업이 대기 상태임 ()을 나타내며, 기본적으로 나중 단계의 작업들은 트리거 작업이 완료될 때까지 시작하지 않습니다.
- 만약 다운스트림 파이프라인에 실패한 작업이 있지만 작업이
allow_failure: true
을 사용한 경우, 다운스트림 파이프라인은 성공적으로 간주되며, 트리거 작업은 성공으로 나타납니다.
trigger:forward
trigger:forward
를 사용하여 하위 파이프라인과 다중 프로젝트 파이프라인으로 전달할 항목을 지정할 수 있습니다.
trigger:forward
로 부모-자식 파이프라인
및 다중 프로젝트 파이프라인으로 전달되는 항목을 제어할 수 있습니다.
가능한 입력값:
-
yaml_variables
:true
(기본값) 또는false
.true
인 경우, 트리거 작업에 정의된 변수가 다운스트림 파이프라인에 전달됩니다. -
pipeline_variables
:true
또는false
(기본값).true
인 경우, 수동 파이프라인 변수 및 일정에 따른 파이프라인 변수 이 다운스트림 파이프라인에 전달됩니다.
trigger:forward
의 예시:
CI/CD 변수 MYVAR = my value
로 이 파이프라인을 수동으로 실행:
variables: # 각 작업에 대한 기본 변수
VAR: value
# 기본 동작:
# - VAR이 자식에게 전달됨
# - MYVAR는 자식에게 전달되지 않음
child1:
trigger:
include: .child-pipeline.yml
# 파이프라인 변수 전달:
# - VAR이 자식에게 전달됨
# - MYVAR는 자식에게 전달됨
child2:
trigger:
include: .child-pipeline.yml
forward:
pipeline_variables: true
# YAML 변수를 전달하지 않음:
# - VAR가 자식에게 전달되지 않음
# - MYVAR가 자식에게 전달되지 않음
child3:
trigger:
include: .child-pipeline.yml
forward:
yaml_variables: false
추가 세부 정보:
-
trigger:forward
로 다운스트림 파이프라인에 전달된 CI/CD 변수는 가장 높은 우선순위를 가집니다. 동일한 이름의 변수가 다운스트림 파이프라인에서 정의된 경우 해당 변수는 전달된 변수에 덮어쓰입니다.
variables
CI/CD 변수를 작업에 정의하는 데 variables
를 사용합니다.
키워드 유형: 글로벌 및 작업 키워드. 글로벌 수준과 작업 수준에서 사용할 수 있습니다.
variables
를 글로벌 키워드로 정의하면 모든 작업에 대한 기본 변수로 작동합니다. 각 변수는 파이프라인이 생성될 때 모든 작업 구성으로 복사됩니다. 작업에 이미 해당 변수가 정의된 경우 작업 수준 변수가 우선합니다.
글로벌 수준에서 정의된 변수는 include
와 같은 기타 글로벌 키워드의 입력으로 사용할 수 없습니다. 이러한 변수는 script
, before_script
, after_script
섹션에서 작업 수준 및 rules
과 같은 일부 작업 키워드의 입력에만 사용할 수 있습니다.
가능한 입력: 변수 이름 및 값 쌍:
- 이름은 숫자, 문자 및 밑줄(
_
)만 사용할 수 있습니다. 일부 셸에서는 첫 번째 문자가 문자여야 합니다. - 값은 문자열이어야 합니다.
CI/CD 변수 지원됨.
variables
의 예시:
variables:
DEPLOY_SITE: "https://example.com/"
deploy_job:
stage: deploy
script:
- deploy-script --url $DEPLOY_SITE --path "/"
environment: production
deploy_review_job:
stage: deploy
variables:
REVIEW_PATH: "/review"
script:
- deploy-review-script --url $DEPLOY_SITE --path $REVIEW_PATH
environment: production
추가 세부정보:
- 모든 YAML로 정의된 변수는 연결된 Docker 서비스 컨테이너에도 설정됩니다.
- YAML로 정의된 변수는 민감한 프로젝트 구성을 위한 것입니다. 민감한 정보는 protected variables나 CI/CD secrets에 저장하세요.
- 수동 파이프라인 변수 및 예약된 파이프라인 변수는 기본적으로 하류 파이프라인으로 전달되지 않습니다. 이러한 변수를 하류 파이프라인으로 전달하려면 trigger:forward를 사용하세요.
관련 주제:
- 사전 정의된 변수는 실행 중에 러너가 자동으로 생성하고 작업에서 사용할 수 있는 변수입니다.
- 변수를 사용하여 러너 동작 구성할 수 있습니다.
variables:description
- GitLab 13.7에서 도입되었습니다.
description
키워드를 사용하여 파이프라인 수준(글로벌) 변수에 대한 설명을 정의합니다. 수동으로 파이프라인을 실행할 때 미리 채워진 변수 이름과 함께 표시됩니다.
키워드 유형: 글로벌 키워드. 작업 수준 변수에는 사용할 수 없습니다.
가능한 입력:
- 문자열.
variables:description
의 예시:
variables:
DEPLOY_NOTE:
description: "The deployment note. Explain the reason for this deployment."
추가 세부정보:
-
value
없이 사용하면 수동으로 트리거되지 않은 파이프라인에 해당 변수가 존재하며, 기본값은 빈 문자열(''
)입니다.
variables:value
- GitLab 13.7에서 도입되었습니다.
value
키워드를 사용하여 파이프라인 수준(글로벌) 변수의 값을 정의합니다. variables: description
과 함께 사용하면 파이프라인을 수동으로 실행할 때 변수 값이 미리 채워짐니다.
키워드 유형: 글로벌 키워드. 작업 수준 변수에는 사용할 수 없습니다.
가능한 입력:
- 문자열.
variables:value
의 예시:
variables:
DEPLOY_ENVIRONMENT:
value: "staging"
description: "The deployment target. Change this variable to 'canary' or 'production' if needed."
추가 세부정보:
-
variables: description
없이 사용할 경우 동작은variables
와 동일합니다.
variables:options
- GitLab 15.7에서 도입되었습니다.
variables:options
를 사용하여 수동으로 파이프라인을 실행할 때 UI에서 선택 가능한 값 목록을 구성합니다.
variables:value
와 함께 사용해야 하며, value
에 정의된 문자열은 다음을 만족해야 합니다:
-
options
배열의 문자열 중 하나여야 합니다. - 기본 선택 사항입니다.
description
이 없는 경우 이 키워드는 효력이 없습니다.
키워드 유형: 글로벌 키워드. 작업 수준 변수에는 사용할 수 없습니다.
가능한 입력:
- 문자열 배열.
variables:options
의 예시:
variables:
DEPLOY_ENVIRONMENT:
value: "staging"
options:
- "production"
- "staging"
- "canary"
description: "The deployment target. Set to 'staging' by default."
변수:확장
-
GitLab 15.6에 도입되었으며 기본으로 비활성화된
ci_raw_variables_in_yaml_config
라는 플래그와 함께. - GitLab 15.6에서 GitLab.com에서 활성화됨.
- GitLab 15.7에서 Self-managed에서 활성화됨.
-
GitLab 15.8에서 General Availability됨. 기능 플래그
ci_raw_variables_in_yaml_config
삭제.
expand
키워드를 사용하여 변수를 확장 가능하게 또는 그렇지 않게 구성합니다.
키워드 유형: 글로벌 및 작업 키워드. 전역 수준과 작업 수준에서 사용할 수 있습니다.
가능한 입력:
-
true
(기본값): 변수는 확장 가능합니다. -
false
: 변수는 확장할 수 없습니다.
변수:확장
예시:
variables:
VAR1: value1
VAR2: value2 $VAR1
VAR3:
value: value3 $VAR1
expand: false
-
VAR2
의 결과는value2 value1
입니다. -
VAR3
의 결과는value3 $VAR1
입니다.
추가 정보:
-
확장
키워드는 전역 및 작업 수준variables
키워드와 함께 사용할 수 있습니다.rules:variables
또는workflow:rules:variables
와 함께 사용할 수 없습니다.
when
작업이 실행되는 조건을 구성하기 위해 when
을 사용합니다. 작업 내에서 정의되지 않은 경우
기본값은 when: on_success
입니다.
키워드 유형: 작업 키워드. 작업의 일부로 사용할 수 있습니다. workflow:rules
에서도 when: always
및 when: never
를 사용할 수 있습니다.
가능한 입력:
-
on_success
(기본값): 이전 단계의 작업 중 실패한 작업이 없을 때 또는allow_failure: true
가 있는 경우에만 작업을 실행합니다. -
on_failure
: 이전 단계에서 적어도 한 작업이 실패할 때 작업을 실행합니다. 이전 단계의allow_failure: true
가 있는 작업은 항상 성공으로 간주됩니다. -
never
: 이전 단계의 상태에 관계없이 작업을 실행하지 않습니다.rules
섹션 또는workflow:rules
에서만 사용할 수 있습니다. -
always
: 이전 단계의 상태에 관계없이 작업을 실행합니다.workflow:rules
에서도 사용할 수 있습니다. -
manual
: 수동으로 트리거된 경우에만 작업을 실행합니다. -
delayed
: 지정된 기간 동안 작업의 실행을 지연시킵니다.
when
예시:
stages:
- build
- cleanup_build
- test
- deploy
- cleanup
build_job:
stage: build
script:
- make build
cleanup_build_job:
stage: cleanup_build
script:
- cleanup build when failed
when: on_failure
test_job:
stage: test
script:
- make test
deploy_job:
stage: deploy
script:
- make deploy
when: manual
environment: production
cleanup_job:
stage: cleanup
script:
- cleanup after jobs
when: always
이 예시에서 스크립트는 다음을 실행합니다:
-
build_job
이 실패할 때만cleanup_build_job
을 실행합니다. - 어떤 경우에도
cleanup_job
을 파이프라인의 마지막 단계로 실행합니다. - GitLab UI에서 수동으로 실행할 때
deploy_job
을 실행합니다.
추가 정보:
-
GitLab 13.5 및 이후에는
when:manual
을trigger
와 함께 동일한 작업에서 사용할 수 있습니다. GitLab 13.4 및 이전 버전에서는 함께 사용하면jobs:#{job-name} when should be on_success, on_failure or always
에러가 발생합니다. -
when: manual
의 기본 동작은allow_failure
가true
로 변경됩니다. 그러나when: manual
을rules
과 함께 사용하면allow_failure
가 기본적으로false
로 설정됩니다.
관련 주제:
사용되지 않는 키워드
다음 키워드는 사용되지 않습니다.
참고: 이러한 키워드는 여전히 호환성 유지를 위해 사용할 수는 있지만, 향후 주요 마일스톤에서 제거될 수 있습니다.
전역으로 정의된 image
, services
, cache
, before_script
, after_script
image
, services
, cache
, before_script
, 그리고 after_script
를 전역으로 정의하는 것은 사용되지 않습니다.
이러한 키워드를 최상위 수준에서 사용하는 것은 여전히 가능하지만, 호환성을 위해
향후 마일스톤에서 제거될 수 있습니다.
대신 default
를 사용하세요. 예를 들어:
default:
image: ruby:3.0
services:
- docker:dind
cache:
paths: [vendor/]
before_script:
- bundle config set path vendor/bundle
- bundle install
after_script:
- rm -rf tmp/
only
/ except
참고:
only
와 except
는 사용되지 않으며 활발히 개발되고 있지 않습니다. 이러한 키워드는
여전히 호환성을 유지하기 위해 사용할 수는 있지만, 향후 마일스톤에서 제거될 수
있습니다. 파이프라인에 작업을 추가할 시기를 제어하려면 대신 rules
을 사용하세요.
파이프라인에 작업을 추가할 시기를 제어하기 위해 only
와 except
를 사용할 수 있습니다.
- 작업이 실행되는 시기를 정의하려면
only
를 사용하세요. - 작업이 실행되지 않는 시기를 정의하려면
except
를 사용하세요.
더 많은 세부 정보 및 예제는 only
및 except
로 작업 실행 시기 지정를 참조하세요.
only:refs
/ except:refs
참고:
only:refs
와 except:refs
는 사용되지 않으며 활발히 개발되고 있지 않습니다. 이러한 키워드는
여전히 호환성을 유지하기 위해 사용할 수는 있지만, 향후 마일스톤에서 제거될 수
있습니다. 참조, 정규식 또는 변수를 사용하여 파이프라인에 작업을 추가할 시기를 제어하려면
대신 rules:if
을 사용하세요.
only:refs
와 except:refs
키워드를 사용하여 브랜치 이름 또는 파이프라인 유형에 기반하여
파이프라인에 작업을 추가할 시기를 제어할 수 있습니다.
키워드 유형: 작업 키워드입니다. 작업의 일부로만 사용할 수 있습니다.
가능한 입력: 브랜치 이름(예: main
또는 my-feature-branch
),
브랜치 이름과 일치하는 정규식(예: /^feature-.*/
), 다음과 같은 키워드를 포함하는 배열:
값 | 설명 |
---|---|
api
| 파이프라인 API에서 트리거된 파이프라인에 대한 값. |
branches
| 파이프라인의 Git 참조가 브랜치 일 때. |
chat
| GitLab ChatOps 명령을 사용하여 생성된 파이프라인에 대한 값. |
external
| GitLab 이외의 CI 서비스를 사용할 때. |
external_pull_requests
| GitHub에서 외부 풀 리퀘스트가 생성되거나 업데이트될 때(외부 풀 리퀘스트에 대한 파이프라인 참조). |
merge_requests
| 병합 요청이 생성되거나 업데이트될 때. 병합 요청 파이프라인, 병합 결과 파이프라인 및 병합 트레인이 가능해집니다. |
pipelines
|
CI_JOB_TOKEN 을 사용하여 API를 통해 다중 프로젝트 파이프라인을 트리거하거나 trigger 키워드를 사용하여 생성된 경우에 대한 값.
|
pushes
|
git push 이벤트로 트리거된 파이프라인에 대한 값. 브랜치 및 태그 모두 포함됩니다.
|
schedules
| 예약된 파이프라인에 대한 값. |
tags
| 파이프라인의 Git 참조가 태그 일 때. |
triggers
| 트리거 토큰을 사용하여 생성된 파이프라인에 대한 값. |
web
| GitLab UI에서 Run pipeline을 선택하여 프로젝트의 Build > 파이프라인 섹션에서 생성된 파이프라인에 대한 값. |
only:refs
및 except:refs
의 예시:
job1:
script: echo
only:
- main
- /^issue-.*$/
- merge_requests
job2:
script: echo
except:
- main
- /^stable-branch.*$/
- schedules
추가 세부 정보:
- 예약된 파이프라인에서 실행되므로
schedules
와 함께 구성된 작업은only: branches
를 사용하는 작업이 예약된 파이프라인에서 실행되지 않도록 합니다. -
다른 키워드 없이 사용되는
only
또는except
는only:refs
또는except:refs
와 동일합니다. 예를 들어, 다음 두 개의 작업 구성은 동일한 동작을 합니다:job1: script: echo only: - branches job2: script: echo only: refs: - branches
-
만약 작업이
only
,except
, 또는rules
를 사용하지 않는 경우,only
는 기본적으로branches
및tags
로 설정됩니다. 예를 들어,job1
과job2
는 동일합니다:job1: script: echo "test" job2: script: echo "test" only: - branches - tags
only:variables
/ except:variables
주의: only:variables
및 except:variables
은 폐기되었으며 더 이상 활발하게 개발되지 않습니다.
이러한 키워드는 하위 호환성을 보장하기 위해 여전히 사용할 수 있지만 향후 마일스톤에서 제거 될 수 있습니다.
파이프라인에 작업을 추가할 시기를 제어하려면 refs, 정규 표현식 또는 변수를 사용하여 rules:if
를 대신 사용하십시오.
파이프라인에 작업을 추가할 때 only:variables
또는 except:variables
키워드를 사용하여 CI/CD 변수의 상태에 따라 조절할 수 있습니다.
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.
가능한 입력값:
- CI/CD 변수 표현식의 배열.
only:variables
의 예시:
deploy:
script: cap staging deploy
only:
variables:
- $RELEASE == "staging"
- $STAGING
관련 주제:
only:changes
/ except:changes
only:variables
및 except:variables
주의: only:changes
및 except:changes
는 폐기되었으며 더 이상 활발하게 개발되지 않습니다.
이러한 키워드는 하위 호환성을 보장하기 위해 여전히 사용할 수 있지만 향후 마일스톤에서 제거 될 수 있습니다.
파일이 변경될 때 작업을 파이프라인에 추가할 시기를 제어하려면 rules:changes
를 사용하십시오.
Git 푸시 이벤트가 파일을 수정하는 경우 작업을 실행하려면 only
와 함께 changes
키워드를 사용하거나 작업을 건너뛰려면 except
와 함께 changes
를 사용하세요.
changes
를 다음 refs와 함께 사용하는 파이프라인에서 사용하세요:
- 브랜치
- external_pull_requests
- merge_requests
(병합 요청 파이프라인에서 only:changes
를 사용하는 방법에 대한 추가 정보을 참조하십시오)
키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.
가능한 입력값: 파일 경로를 포함한 배열 또는 다음 중 하나 이상:
- 파일 경로.
- 단일 디렉터리에 대한 와일드카드 경로, 예: path/to/directory/*
.
- 디렉터리 및 해당 하위 디렉터리에 대한 와일드카드 경로, 예: path/to/directory/**/*
.
- 동일한 확장자 또는 여러 확장자를 가진 모든 파일에 대한 와일드카드 glob 경로, 예: *.md
또는 path/to/directory/*.{rb,py,sh}
.
- 따옴표로 묶인 루트 디렉터리 또는 모든 디렉터리에있는 파일에 대한 와일드카드 경로.
예: "*.json"
또는 "**/*.json"
.
only:changes
의 예시:
docker build:
script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
only:
refs:
- branches
changes:
- Dockerfile
- docker/scripts/*
- dockerfiles/**/*
- more_scripts/*.{rb,py,sh}
- "**/*.json"
추가 정보:
- 일치하는 파일 중 하나라도 변경된 경우(
OR
연산)changes
는true
로 해석됩니다. - Glob 패턴은 Ruby의
File.fnmatch
및 flags을 사용하여 해석됩니다. -
branches
,external_pull_requests
, 또는merge_requests
이외의 refs를 사용하는 경우changes
는 주어진 파일이 새로운 것인지 구별하지 못하고 항상true
를 반환합니다. - 다른 refs와 함께
only: changes
를 사용하는 경우 작업은 변경 사항을 무시하고 항상 실행합니다. - 다른 refs와 함께
except: changes
를 사용하는 경우 작업은 변경 사항을 무시하고 절대로 실행하지 않습니다.
관련 주제:
-
only: changes
및except: changes
예시. - 파이프라인이 성공하면 병합 요청이만 항상 성공한 파이프라인이 있는 경우 병합 허용하기
changes
를 사용하는 경우 반드시only:merge_requests
를 사용. -
다음
only: changes
사용 시 작업 또는 파이프라인이 예기치 않게 실행될 수 있음.
only:kubernetes
/ except:kubernetes
참고:
only:kubernetes
및 except:kubernetes
는 폐기되었으며 더 이상 활발하게 개발되지 않습니다.
이러한 키워드는 여전히 하위 호환성을 보장하기 위해 사용할 수 있지만, 향후 마일스톤에서 삭제되거나 예정될 수 있습니다. 프로젝트에서 Kubernetes 서비스가 활성화된 경우 작업이 파이프라인에 추가되는지 여부를 제어하려면 rules:if
를 CI_KUBERNETES_ACTIVE
미리 정의된 CI/CD 변수와 함께 사용하십시오.
프로젝트에서 Kubernetes 서비스가 활성화된 경우 작업이 파이프라인에 추가되는지 여부를 제어하려면 only:kubernetes
또는 except:kubernetes
을 사용하십시오.
키워드 유형: 작업별. 작업의 일부로만 사용할 수 있습니다.
가능한 입력값:
-
kubernetes
전략은active
키워드만 허용합니다.
only:kubernetes
의 예시:
deploy:
only:
kubernetes: active
이 예시에서 deploy
작업은 프로젝트에서 Kubernetes 서비스가 활성화된 경우에만 실행됩니다.