GitLab 템플릿 컬렉션에서 가져온 파일

요약

이 문서는 GitLab .gitlab-ci.yml 파일의 설정 옵션 목록입니다. .gitlab-ci.yml 파일을 편집할 때는 CI Lint 도구로 유효성을 검사할 수 있습니다. GitLab CI/CD 설정은 YAML 형식을 사용하므로, 별도로 명시되지 않는 한 키워드 순서는 중요하지 않습니다.

이 문서는 GitLab .gitlab-ci.yml 파일의 설정 옵션 목록입니다. 이 파일에서 파이프라인을 구성하는 CI/CD job을 정의합니다.

이미 기본 CI/CD 개념에 익숙한 경우, 간단한 또는 복잡한 파이프라인을 보여주는 튜토리얼에 따라 직접 .gitlab-ci.yml 파일을 작성해 보세요.
예시 모음은 GitLab CI/CD 예시를 참조하세요.
엔터프라이즈에서 사용되는 대규모 .gitlab-ci.yml 파일을 보려면 gitlab의 .gitlab-ci.yml 파일을 참조하세요.

.gitlab-ci.yml 파일을 편집할 때는 CI Lint 도구로 유효성을 검사할 수 있습니다.

GitLab CI/CD 설정은 YAML 형식을 사용하므로, 별도로 명시되지 않는 한 키워드 순서는 중요하지 않습니다.

보다 동적인 파이프라인 설정 옵션은 CI/CD 표현식을 사용하세요.

키워드#

GitLab CI/CD 파이프라인 설정에는 다음이 포함됩니다:

파이프라인 동작을 설정하는 전역 키워드:

키워드	설명
`default`	job 키워드의 사용자 정의 기본값.
`include`	다른 YAML 파일에서 설정을 가져옵니다.
`stages`	파이프라인 Stage의 이름과 순서.
`variables`	파이프라인의 모든 job에 대한 기본 CI/CD 변수를 정의합니다.
`workflow`	어떤 유형의 파이프라인이 실행될지 제어합니다.

헤더 키워드

키워드 설명

spec 외부 설정 파일의 사양을 정의합니다.

키워드	설명
`spec`	외부 설정 파일의 사양을 정의합니다.

job 키워드로 설정된 Jobs:

키워드	설명
`after_script`	job 후 실행되는 명령어 세트를 재정의합니다.
`allow_failure`	job이 실패해도 됩니다. 실패한 job은 파이프라인을 실패시키지 않습니다.
`artifacts`	job 성공 시 job에 첨부할 파일 및 디렉토리 목록.
`before_script`	job 전 실행되는 명령어 세트를 재정의합니다.
`cache`	이후 실행 간에 캐시해야 할 파일 목록.
`coverage`	특정 job에 대한 코드 커버리지 설정.
`dast_configuration`	job 수준에서 DAST 프로필의 설정을 사용합니다.
`dependencies`	아티팩트를 가져올 job 목록을 제공하여 특정 job에 전달되는 아티팩트를 제한합니다.
`environment`	job이 배포하는 환경의 이름.
`extends`	이 job이 상속받는 설정 항목.
`identity`	페더레이션 ID를 사용하여 서드파티 서비스로 인증합니다.
`image`	Docker 이미지를 사용합니다.
`inherit`	모든 job이 상속받을 전역 기본값을 선택합니다.
`interruptible`	새 실행으로 인해 불필요해진 경우 job을 취소할 수 있는지 정의합니다.
`manual_confirmation`	수동 job에 대한 사용자 정의 확인 메시지를 정의합니다.
`needs`	Stage 순서보다 이른 시점에 job을 실행합니다.
`pages`	GitLab Pages와 함께 사용하기 위해 job 결과물을 업로드합니다.
`parallel`	병렬로 실행할 job 인스턴스 수.
`release`	러너가 릴리스 객체를 생성하도록 지시합니다.
`resource_group`	job 동시성을 제한합니다.
`retry`	실패 시 job이 자동으로 재시도할 시기와 횟수.
`rules`	job의 선택된 속성과 job 생성 여부를 평가하고 결정하는 조건 목록.
`script`	러너가 실행하는 셸 스크립트.
`run`	러너가 실행하는 run 설정.
`secrets`	job에 필요한 CI/CD 시크릿.
`services`	Docker 서비스 이미지를 사용합니다.
`stage`	job stage를 정의합니다.
`start_in`	지정된 기간 동안 job 실행을 지연합니다. `when: delayed`가 필요합니다.
`tags`	러너를 선택하는 데 사용되는 태그 목록.
`timeout`	프로젝트 전체 설정보다 우선하는 사용자 정의 job 수준 타임아웃을 정의합니다.
`trigger`	다운스트림 파이프라인 트리거를 정의합니다.
`variables`	개별 job에 대한 CI/CD 변수를 정의합니다.
`when`	job 실행 시기.

더 이상 사용을 권장하지 않는 더 이상 사용되지 않는 키워드.

전역 키워드#

일부 키워드는 job에 정의되지 않습니다. 이러한 키워드는 파이프라인 동작을 제어하거나 추가 파이프라인 설정을 가져옵니다.

`default`#

히스토리

id_tokens 지원이 GitLab 16.4에서 도입되었습니다.

일부 키워드에 대한 전역 기본값을 설정할 수 있습니다. 각 기본 키워드는 해당 키워드가 이미 정의되지 않은 모든 job에 복사됩니다.

기본 설정은 job 설정과 병합되지 않습니다. job에 이미 키워드가 정의된 경우, job 키워드가 우선하며 해당 키워드의 기본 설정은 사용되지 않습니다.

키워드 유형: 전역 키워드.

지원되는 값: 이러한 키워드는 사용자 정의 기본값을 가질 수 있습니다:

after_script
artifacts
before_script
cache
hooks
id_tokens
image
interruptible
retry
services
tags 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는 파이프라인의 모든 job에 대한 기본 키워드입니다.
rspec job에는 image 또는 retry가 정의되어 있지 않으므로, image: ruby:3.0과 retry: 2의 기본값을 사용합니다.
rspec 2.7 job에는 retry가 정의되어 있지 않지만, image가 명시적으로 정의되어 있습니다. 기본 retry: 2를 사용하지만, 기본 image는 무시하고 job에 정의된 image: ruby:2.7을 사용합니다.

추가 세부 정보:

inherit:default로 job의 기본 키워드 상속을 제어합니다.
전역 기본값은 다운스트림 파이프라인을 트리거한 업스트림 파이프라인과 독립적으로 실행되는 다운스트림 파이프라인에 전달되지 않습니다.

`include`#

include를 사용하여 CI/CD 설정에 외부 YAML 파일을 포함합니다. 긴 .gitlab-ci.yml 파일을 여러 파일로 분할하여 가독성을 높이거나, 여러 곳에서 동일한 설정의 중복을 줄일 수 있습니다.

템플릿 파일을 중앙 리포지터리에 저장하고 프로젝트에 포함시킬 수도 있습니다.

include 파일은:

.gitlab-ci.yml 파일의 내용과 병합됩니다.
include 키워드의 위치에 관계없이 항상 먼저 평가되고 .gitlab-ci.yml 파일의 내용과 병합됩니다.

모든 파일을 해석하는 시간 제한은 30초입니다.

키워드 유형: 전역 키워드.

지원되는 값: include 서브키:

include:component
include:local
include:project
include:remote
include:template

그리고 선택적으로:

include:inputs
include:rules
include:integrity
include:cache

추가 세부 정보:

include 키워드와 함께 사용할 수 있는 특정 CI/CD 변수만 사용 가능합니다.
병합을 사용하여 로컬에서 포함된 CI/CD 설정을 사용자 정의하고 재정의합니다.
.gitlab-ci.yml 파일에 동일한 job 이름이나 전역 키워드가 있으면 포함된 설정을 재정의할 수 있습니다. 두 설정이 병합되며, .gitlab-ci.yml 파일의 설정이 포함된 설정보다 우선합니다.
다음을 재실행하는 경우:
- Job의 경우: include 파일이 다시 가져와지지 않습니다. 파이프라인의 모든 job은 파이프라인 생성 시 가져온 설정을 사용합니다. 소스 include 파일에 대한 변경 사항은 job 재실행에 영향을 미치지 않습니다.
- 파이프라인의 경우: include 파일이 다시 가져와집니다. 마지막 파이프라인 실행 이후 변경된 경우, 새 파이프라인은 변경된 설정을 사용합니다.
중첩된 것을 포함하여 기본적으로 파이프라인당 최대 150개의 include를 가질 수 있습니다. 추가로:
- GitLab 16.0 이상에서 GitLab Self-Managed 사용자는 최대 include 값을 변경할 수 있습니다.
- GitLab 15.10 이상에서 최대 150개의 include를 가질 수 있습니다. 중첩 include에서는 동일한 파일을 여러 번 포함할 수 있지만, 중복 include는 한도에 포함됩니다.
- GitLab 14.9부터 GitLab 15.9까지 최대 100개의 include를 가질 수 있습니다. 동일한 파일을 중첩 include에 여러 번 포함할 수 있지만, 중복은 무시됩니다.

`include:component`#

include:component를 사용하여 파이프라인 설정에 CI/CD 컴포넌트를 추가합니다.

키워드 유형: 전역 키워드.

지원되는 값: <fully-qualified-domain-name>/<project-path>/<component-name>@<specific-version> 형식으로 된 CI/CD 컴포넌트의 전체 주소.

include:component 예시:

include:
  - component: $CI_SERVER_FQDN/my-org/security-components/secret-detection@1.0

관련 항목:

CI/CD 컴포넌트 사용.

`include:local`#

include:local을 사용하여 include 키워드가 포함된 설정 파일과 동일한 리포지터리 및 브랜치에 있는 파일을 포함합니다. 심볼릭 링크 대신 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 키워드가 포함된 파일의 위치를 기준으로 항상 평가됩니다. 다른 프로젝트의 설정 파일에 중첩 include가 있는 경우, include: local은 해당 다른 프로젝트에서 파일을 확인합니다.

`include:project`#

동일한 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 키워드가 포함된 파일의 위치를 기준으로 항상 평가됩니다. 다른 프로젝트의 설정 파일에 중첩 include가 있는 경우, include: local은 해당 다른 프로젝트에서 파일을 확인합니다.
파이프라인이 시작되면, 모든 방법으로 포함된 .gitlab-ci.yml 파일 설정이 평가됩니다. 설정은 시점의 스냅샷이며 데이터베이스에 저장됩니다. GitLab은 다음 파이프라인이 시작될 때까지 참조된 .gitlab-ci.yml 파일 설정에 대한 변경 사항을 반영하지 않습니다.
다른 비공개 프로젝트에서 YAML 파일을 포함하는 경우, 파이프라인을 실행하는 사용자가 두 프로젝트 모두의 멤버여야 하며 파이프라인 실행에 적절한 권한을 가져야 합니다. 사용자가 포함된 파일 중 하나에 접근 권한이 없는 경우 not found or access denied 오류가 표시될 수 있습니다.
다른 프로젝트의 CI/CD 설정 파일을 포함할 때 주의하세요. CI/CD 설정 파일이 변경될 때 파이프라인이나 알림이 트리거되지 않습니다. 보안 관점에서 이는 서드파티 종속성을 가져오는 것과 유사합니다. ref를 위해 다음을 고려하세요:
- 가장 안정적인 옵션인 특정 SHA 해시를 사용합니다. 짧은 SHA 해시가 ref에 대해 모호할 수 있으므로 원하는 커밋이 참조되도록 40자 전체 SHA 해시를 사용합니다.
- 다른 프로젝트의 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는 공개 사용자로서 컨텍스트 없이 실행되므로, 공개 프로젝트나 템플릿만 포함할 수 있습니다. 중첩 include의 include 섹션에서는 변수를 사용할 수 없습니다.
다른 프로젝트의 CI/CD 설정 파일을 포함할 때 주의하세요. 다른 프로젝트의 파일이 변경될 때 파이프라인이나 알림이 트리거되지 않습니다. 보안 관점에서 이는 서드파티 종속성을 가져오는 것과 유사합니다. 포함된 파일의 무결성을 확인하려면 integrity 키워드 사용을 고려하세요. 소유한 다른 GitLab 프로젝트로 링크하는 경우, 변경 관리 규칙을 적용하기 위해 보호된 브랜치와 보호된 태그 사용을 모두 고려하세요.

`include:template`#

include:template을 사용하여 .gitlab-ci.yml 템플릿을 포함합니다.

키워드 유형: 전역 키워드.

지원되는 값:

CI/CD 템플릿의 파일 이름, 예를 들어 Auto-DevOps.gitlab-ci.yml. 모든 템플릿이 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의 include 섹션에서는 변수를 사용할 수 없습니다.

`include:inputs`#

히스토리

GitLab 15.11에서 베타 기능으로 도입되었습니다.
GitLab 17.0에서 일반 제공되었습니다.

포함된 설정이 spec:inputs를 사용하고 파이프라인에 추가되는 경우, include: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를 사용할 때 입력값 설정.

`include:rules`#

rules와 include를 함께 사용하여 다른 설정 파일을 조건부로 포함할 수 있습니다.

키워드 유형: 전역 키워드.

지원되는 값: 이 rules 서브키:

rules:if.
rules:exists.
rules:changes.

일부 CI/CD 변수가 지원됩니다.

include:rules 예시:

include:
  - local: build_jobs.yml
    rules:
      - if: $INCLUDE_BUILDS == "true"

test-job:
  stage: test
  script: echo "This is a test job"

이 예시에서 INCLUDE_BUILDS 변수가:

true인 경우: build_jobs.yml 설정이 파이프라인에 포함됩니다.
true가 아니거나 존재하지 않는 경우: build_jobs.yml 설정이 파이프라인에 포함되지 않습니다.

관련 항목:

include와 함께 사용하는 예시:
- rules:if.
- rules:changes.
- rules:exists.

`include:integrity`#

히스토리

GitLab 17.9에서 도입되었습니다.

include:remote와 함께 integrity를 사용하여 포함된 원격 파일의 SHA256 해시를 지정합니다. integrity가 실제 내용과 일치하지 않으면, 원격 파일이 처리되지 않고 파이프라인이 실패합니다.

키워드 유형: 전역 키워드.

지원되는 값: 포함된 내용의 Base64 인코딩된 SHA256 해시.

include:integrity 예시:

include:
  - remote: 'https://gitlab.com/example-project/-/raw/main/.gitlab-ci.yml'
    integrity: 'sha256-L3/GAoKaw0Arw6hDCKeKQlV1QPEgHYxGBHsH4zG1IY8='

`include:cache`#

히스토리

GitLab 18.9에서 ci_cache_remote_includes라는 기능 플래그와 함께
GitLab 19.0에서 일반 공개. 기능 플래그 ci_cache_remote_includes 제거됨.

include:remote와 함께 cache를 사용하여 가져온 원격 파일 내용을 캐시하고 HTTP 요청을 줄입니다. 활성화되면, 동일한 원격 include를 반복적으로 사용하는 설정의 파이프라인 성능을 개선하기 위해 원격 파일이 지정된 TTL(time-to-live) 동안 캐시됩니다.

캐시 기간을 설정할 때 성능과 최신성 사이의 트레이드오프를 고려하세요. 캐시 기간이 길면 성능이 향상되지만, 원격 파일이 자주 변경되는 경우 오래된 내용을 사용할 수 있습니다.

cache가 정의되지 않으면, 매번 원격 파일이 가져와집니다.

키워드 유형: 전역 키워드.

지원되는 값:

true: 기본 TTL 1시간으로 캐싱을 활성화합니다.
기간(문자열): minutes, hours, 또는 days와 같은 시간 단위를 사용하는 유효한 TTL 기간 문자열(최소 1 minute).

include:cache 예시:

include:
  - remote: 'https://gitlab.com/example-project/-/raw/main/sample1.gitlab-ci.yml'
    cache: true
  - remote: 'https://gitlab.com/example-project/-/raw/main/sample2.gitlab-ci.yml'
    cache: '1 day'

추가 세부 정보:

캐싱은 include:remote에서만 사용 가능합니다.
원격 파일이 캐시된 후, 원격 파일 내용이 변경되더라도 TTL이 만료될 때까지 캐시된 버전이 계속 사용됩니다.
cache와 함께 integrity를 사용하면, 캐시된 내용을 사용할 때도 모든 파이프라인 실행에서 무결성 검사가 수행됩니다.

`stages`#

히스토리

중첩된 문자열 배열 지원이 GitLab 16.9에서 도입되었습니다.

stages를 사용하여 job 그룹을 포함하는 Stage를 정의합니다. job에서 stage를 사용하여 특정 Stage에서 실행되도록 job을 설정합니다.

.gitlab-ci.yml 파일에 stages가 정의되지 않으면, 기본 파이프라인 Stage는 다음과 같습니다:

.pre
build
test
deploy
.post

stages의 항목 순서가 job의 실행 순서를 정의합니다:

동일한 Stage의 job은 병렬로 실행됩니다.
다음 Stage의 job은 이전 Stage의 job이 성공적으로 완료된 후 실행됩니다.

파이프라인에 .pre 또는 .post Stage의 job만 있으면 실행되지 않습니다. 다른 Stage에 최소 하나의 다른 job이 있어야 합니다.

키워드 유형: 전역 키워드.

stages 예시:

stages:
  - build
  - test
  - deploy

이 예시에서:

build의 모든 job이 병렬로 실행됩니다.
build의 모든 job이 성공하면, test job이 병렬로 실행됩니다.
test의 모든 job이 성공하면, deploy job이 병렬로 실행됩니다.
deploy의 모든 job이 성공하면, 파이프라인이 passed로 표시됩니다.

어떤 job이 실패하면, 파이프라인이 failed로 표시되고 이후 Stage의 job은 시작되지 않습니다. 현재 Stage의 job은 중지되지 않고 계속 실행됩니다.

추가 세부 정보:

job이 stage를 지정하지 않으면, job이 test Stage에 할당됩니다.
Stage가 정의되었지만 job이 사용하지 않으면, 파이프라인에서 Stage가 표시되지 않으며, 이는 컴플라이언스 파이프라인 설정에 도움이 될 수 있습니다:
- Stage는 컴플라이언스 설정에서 정의할 수 있지만 사용되지 않으면 숨겨집니다.
- 개발자가 job 정의에 사용하면 정의된 Stage가 표시됩니다.

관련 항목:

Stage 순서를 무시하고 job을 더 일찍 시작하려면 needs 키워드를 사용합니다.

`workflow`#

workflow를 사용하여 파이프라인 동작을 제어합니다.

workflow 설정에서 일부 사전 정의된 CI/CD 변수를 사용할 수 있지만, job이 시작될 때만 정의되는 변수는 사용할 수 없습니다.

관련 항목:

`workflow:auto_cancel:on_new_commit`#

히스토리

GitLab 16.8에서 ci_workflow_auto_cancel_on_new_commit이라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화됩니다.
GitLab 16.9에서 GitLab.com 및 GitLab Self-Managed에서 활성화되었습니다.
GitLab 16.10에서 일반 제공되었습니다. 기능 플래그 ci_workflow_auto_cancel_on_new_commit이 제거되었습니다.

workflow:auto_cancel:on_new_commit을 사용하여 중복 파이프라인 자동 취소 기능의 동작을 설정합니다.

지원되는 값:

conservative: 파이프라인을 취소하되, interruptible: false인 job이 아직 시작되지 않은 경우에만 취소합니다. 정의되지 않은 경우 기본값입니다.
interruptible: interruptible: true인 job만 취소합니다.
none: job을 자동으로 취소하지 않습니다.

workflow:auto_cancel:on_new_commit 예시:

workflow:
  auto_cancel:
    on_new_commit: interruptible

job1:
  interruptible: true
  script: sleep 60

job2:
  interruptible: false  # Default when not defined.
  script: sleep 60

이 예시에서:

새 커밋이 브랜치에 푸시되면, GitLab이 새 파이프라인을 생성하고 job1과 job2가 시작됩니다.
job이 완료되기 전에 새 커밋이 브랜치에 푸시되면, job1만 취소됩니다.

`workflow:auto_cancel:on_job_failure`#

히스토리

GitLab 16.10에서 auto_cancel_pipeline_on_job_failure이라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화됩니다.
GitLab 16.11에서 일반 제공되었습니다. 기능 플래그 auto_cancel_pipeline_on_job_failure이 제거되었습니다.

하나의 job이 실패하는 즉시 취소해야 할 job을 설정하려면 workflow:auto_cancel:on_job_failure를 사용합니다.

지원되는 값:

all: 하나의 job이 실패하는 즉시 파이프라인과 모든 실행 중인 job을 취소합니다.
none: 어떤 job도 자동으로 취소하지 않습니다.

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은 시작되지 않습니다.

관련 항목:

다운스트림 파이프라인에서 상위 파이프라인 자동 취소

`workflow:name`#

히스토리

GitLab 15.5에서 pipeline_name이라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화됩니다.
GitLab 15.7에서 GitLab.com 및 GitLab Self-Managed에서 활성화되었습니다.
GitLab 15.8에서 일반 제공되었습니다. 기능 플래그 pipeline_name이 제거되었습니다.

workflow:에서 name을 사용하여 파이프라인 이름을 정의할 수 있습니다.

모든 파이프라인에 정의된 이름이 할당됩니다. 이름의 앞뒤 공백은 제거됩니다.

지원되는 값:

문자열.
CI/CD 변수.
두 가지의 조합.

workflow:name 예시:

사전 정의된 변수를 사용한 간단한 파이프라인 이름:

workflow:
  name: 'Pipeline for branch: $CI_COMMIT_BRANCH'

파이프라인 조건에 따라 서로 다른 파이프라인 이름을 갖는 설정:

variables:
  PROJECT1_PIPELINE_NAME: 'Default pipeline name'  # A default is not required

workflow:
  name: '$PROJECT1_PIPELINE_NAME'
  rules:
    - if: '$CI_MERGE_REQUEST_LABELS =~ /pipeline:run-in-ruby3/'
      variables:
        PROJECT1_PIPELINE_NAME: 'Ruby 3 pipeline'
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      variables:
        PROJECT1_PIPELINE_NAME: 'MR pipeline: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME'
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH  # For default branch pipelines, use the default name

추가 세부 정보:

이름이 빈 문자열이면, 파이프라인에 이름이 할당되지 않습니다. CI/CD 변수만으로 구성된 이름은 모든 변수도 비어 있는 경우 빈 문자열로 평가될 수 있습니다.
workflow:rules:variables는 모든 job에서 사용할 수 있는 기본 변수가 됩니다. 기본적으로 변수를 다운스트림 파이프라인으로 전달하는 trigger job도 포함됩니다. 다운스트림 파이프라인이 동일한 변수를 사용하는 경우, 변수가 업스트림 변수 값으로 덮어씌워집니다. 다음 중 하나를 수행해야 합니다:
- PROJECT1_PIPELINE_NAME과 같이 모든 프로젝트의 파이프라인 설정에서 고유한 변수 이름을 사용합니다.
- trigger job에서 inherit:variables를 사용하고 다운스트림 파이프라인에 전달하려는 정확한 변수를 나열합니다.

`workflow:rules`#

workflow의 rules 키워드는 job에 정의된 rules와 유사하지만, 전체 파이프라인이 생성될지 여부를 제어합니다.

어떤 규칙도 true로 평가되지 않으면, 파이프라인이 실행되지 않습니다.

지원되는 값: job 수준 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로 끝나지 않고 파이프라인이 다음 중 하나인 경우 파이프라인이 실행됩니다:

머지 리퀘스트
기본 브랜치.

추가 세부 정보:

규칙이 브랜치 파이프라인(기본 브랜치 제외)과 머지 리퀘스트 파이프라인 모두에 일치하면, 중복 파이프라인이 발생할 수 있습니다.
start_in, allow_failure, needs는 workflow:rules에서 지원되지 않지만, 문법 위반을 유발하지 않습니다. 효과가 없더라도 workflow:rules에서 사용하지 마세요. 향후 문법 오류를 유발할 수 있습니다. 자세한 내용은 이슈 436473을 참조하세요.

관련 항목:

`workflow:rules:variables`#

workflow:rules에서 variables를 사용하여 특정 파이프라인 조건에 대한 변수를 정의할 수 있습니다.

조건이 일치하면, 변수가 생성되고 파이프라인의 모든 job에서 사용할 수 있습니다. 변수가 이미 최상위 레벨에서 기본 변수로 정의된 경우, workflow 변수가 우선하여 기본 변수를 재정의합니다.

키워드 유형: 전역 키워드.

지원되는 값: 변수 이름과 값 쌍:

이름은 숫자, 문자, 밑줄(_)만 사용할 수 있습니다.
값은 문자열이어야 합니다.

workflow:rules:variables 예시:

variables:
  DEPLOY_VARIABLE: "default-deploy"

workflow:
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      variables:
        DEPLOY_VARIABLE: "deploy-production"  # Override globally-defined DEPLOY_VARIABLE
    - if: $CI_COMMIT_BRANCH =~ /feature/
      variables:
        IS_A_FEATURE: "true"                  # Define a new variable.
    - if: $CI_COMMIT_BRANCH                   # Run the pipeline in other cases

job1:
  variables:
    DEPLOY_VARIABLE: "job1-default-deploy"
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      variables:                                   # Override DEPLOY_VARIABLE defined
        DEPLOY_VARIABLE: "job1-deploy-production"  # at the job level.
    - when: on_success                             # Run the job in other cases
  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는 모든 job에서 사용할 수 있는 기본 변수가 됩니다. 기본적으로 변수를 다운스트림 파이프라인으로 전달하는 trigger job도 포함됩니다. 다운스트림 파이프라인이 동일한 변수를 사용하는 경우, 변수가 업스트림 변수 값으로 덮어씌워집니다. 다음 중 하나를 수행해야 합니다:
- PROJECT1_VARIABLE_NAME과 같이 모든 프로젝트의 파이프라인 설정에서 고유한 변수 이름을 사용합니다.
- trigger job에서 inherit:variables를 사용하고 다운스트림 파이프라인에 전달하려는 정확한 변수를 나열합니다.

`workflow:rules:auto_cancel`#

히스토리

GitLab 16.8에서 ci_workflow_auto_cancel_on_new_commit이라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화됩니다.
GitLab 16.9에서 GitLab.com 및 GitLab Self-Managed에서 활성화되었습니다.
GitLab 16.10에서 일반 제공되었습니다. 기능 플래그 ci_workflow_auto_cancel_on_new_commit이 제거되었습니다.
workflow:rules의 on_job_failure 옵션이 GitLab 16.10에서 auto_cancel_pipeline_on_job_failure이라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화됩니다.
workflow:rules의 on_job_failure 옵션이 GitLab 16.11에서 일반 제공되었습니다. 기능 플래그 auto_cancel_pipeline_on_job_failure이 제거되었습니다.

workflow:rules:auto_cancel을 사용하여 workflow:auto_cancel:on_new_commit 또는 workflow:auto_cancel:on_job_failure 기능의 동작을 설정합니다.

지원되는 값:

on_new_commit: workflow:auto_cancel:on_new_commit
on_job_failure: workflow:auto_cancel:on_job_failure

workflow:rules:auto_cancel 예시:

workflow:
  auto_cancel:
    on_new_commit: interruptible
    on_job_failure: all
  rules:
    - if: $CI_COMMIT_REF_PROTECTED == 'true'
      auto_cancel:
        on_new_commit: none
        on_job_failure: none
    - when: always                  # Run the pipeline in other cases

test-job1:
  script: sleep 10
  interruptible: false

test-job2:
  script: sleep 10
  interruptible: true

이 예시에서, workflow:auto_cancel:on_new_commit은 기본적으로 모든 job에 대해 interruptible로 설정되고, workflow:auto_cancel:on_job_failure는 all로 설정됩니다. 하지만 보호된 브랜치에서 파이프라인이 실행되면, 규칙이 on_new_commit: none과 on_job_failure: none으로 기본값을 재정의합니다. 예를 들어, 파이프라인이 다음에서 실행되는 경우:

보호되지 않은 브랜치에서 새 커밋이 푸시되면, test-job1은 계속 실행되고 test-job2는 취소됩니다.
보호된 브랜치에서 새 커밋이 푸시되면, test-job1과 test-job2 모두 계속 실행됩니다.

헤더 키워드#

일부 키워드는 YAML 설정 파일의 헤더 섹션에 정의해야 합니다. 헤더는 파일 맨 위에 있어야 하며, ---로 나머지 설정과 구분됩니다.

`spec`#

히스토리

GitLab 15.11에서 베타 기능으로 도입되었습니다.

include 키워드로 파이프라인에 설정이 추가될 때 파이프라인의 동작을 설정하려면 YAML 파일 헤더에 spec 섹션을 추가합니다.

Spec은 설정 파일 상단에 ---로 나머지 설정과 구분되는 헤더 섹션에 선언해야 합니다.

`spec:inputs`#

spec:inputs를 사용하여 CI/CD 설정의 입력값을 정의합니다.

헤더 섹션 외부에서 값을 참조하려면 보간 형식 $[[ inputs.input-id ]]를 사용합니다. 입력값은 파이프라인 생성 중 설정이 가져와질 때 평가되고 보간됩니다. inputs를 사용할 때, 설정이 .gitlab-ci.yml 파일의 내용과 병합되기 전에 보간이 완료됩니다.

키워드 유형: 헤더 키워드. spec은 설정 파일 상단의 헤더 섹션에 선언해야 합니다.

지원되는 값: 예상 입력값을 나타내는 문자열 해시.

spec:inputs 예시:

spec:
  inputs:
    environment:
    job-stage:
---

scan-website:
  stage: $[[ inputs.job-stage ]]
  script: ./scan-website $[[ inputs.environment ]]

추가 세부 정보:

spec:inputs:default를 사용하여 기본값을 설정하지 않는 한 입력값은 필수입니다. include:inputs와 함께 입력값만 사용하지 않는 한 필수 입력값은 피하세요.
spec:inputs:type를 사용하여 다른 입력값 유형을 설정하지 않는 한 입력값은 문자열을 예상합니다.
보간 블록이 포함된 문자열은 1MB를 초과할 수 없습니다.
보간 블록 내의 문자열은 1KB를 초과할 수 없습니다.
새 파이프라인을 실행할 때 입력값을 정의할 수 있습니다.

관련 항목:

spec:inputs로 입력 파라미터 정의.

`spec:inputs:default`#

히스토리

GitLab 15.11에서 베타 기능으로 도입되었습니다.

spec:inputs:default로 기본값을 설정하지 않는 한 포함될 때 입력값은 필수입니다.

기본값이 없도록 하려면 default: ''를 사용합니다.

키워드 유형: 헤더 키워드. spec은 설정 파일 상단의 헤더 섹션에 선언해야 합니다.

지원되는 값: 기본값을 나타내는 문자열, 또는 ''.

spec:inputs:default 예시:

spec:
  inputs:
    website:
    user:
      default: 'test-user'
    flags:
      default: ''
---
# The pipeline configuration would follow...

이 예시에서:

website는 필수이며 정의해야 합니다.
user는 선택적입니다. 정의되지 않으면 값이 test-user입니다.
flags는 선택적입니다. 정의되지 않으면 값이 없습니다.

추가 세부 정보:

다음 경우에 파이프라인이 유효성 검사 오류로 실패합니다:
- default와 options를 함께 사용하지만, 기본값이 나열된 옵션 중 하나가 아닌 경우.
- default와 regex를 함께 사용하지만, 기본값이 정규식과 일치하지 않는 경우.
- 값이 type과 일치하지 않는 경우.

`spec:inputs:description`#

히스토리

GitLab 16.5에서 도입되었습니다.

특정 입력값에 설명을 제공하려면 description을 사용합니다. 설명은 입력값의 동작에 영향을 미치지 않으며, 파일 사용자가 입력값을 이해하는 데 도움을 주기 위해서만 사용됩니다.

키워드 유형: 헤더 키워드. spec은 설정 파일 상단의 헤더 섹션에 선언해야 합니다.

지원되는 값: 설명을 나타내는 문자열.

spec:inputs:description 예시:

spec:
  inputs:
    flags:
      description: 'Sample description of the `flags` input details.'
---
# The pipeline configuration would follow...

`spec:inputs:options`#

히스토리

GitLab 16.6에서 도입되었습니다.

입력값에 대한 허용 값 목록을 지정하려면 options를 사용합니다. 입력당 최대 50개의 옵션이 있습니다.

키워드 유형: 헤더 키워드. spec은 설정 파일 상단의 헤더 섹션에 선언해야 합니다.

지원되는 값: 입력 옵션의 배열. string과 number type 입력값만 옵션과 함께 사용할 수 있습니다.

spec:inputs:options 예시:

spec:
  inputs:
    environment:
      options:
        - development
        - staging
        - production
---
# The pipeline configuration would follow...

이 예시에서:

environment는 필수이며 목록의 값 중 하나로 정의해야 합니다.

추가 세부 정보:

다음 경우에 파이프라인이 유효성 검사 오류로 실패합니다:
- 입력값이 options와 default를 함께 사용하지만, 기본값이 나열된 옵션 중 하나가 아닌 경우.
- 입력 옵션이 type과 일치하지 않는 경우. options를 사용할 때는 boolean이 아닌 string 또는 number만 가능합니다.

`spec:inputs:regex`#

히스토리

GitLab 16.5에서 도입되었습니다.

입력값이 일치해야 하는 정규 표현식을 지정하려면 spec:inputs:regex를 사용합니다.

키워드 유형: 헤더 키워드. spec은 설정 파일 상단의 헤더 섹션에 선언해야 합니다.

지원되는 값: 정규 표현식이어야 합니다.

spec:inputs:regex 예시:

spec:
  inputs:
    version:
      regex: ^v\d\.\d+(\.\d+)?$
---
# The pipeline configuration would follow...

이 예시에서, v1.0 또는 v1.2.3의 입력값은 정규 표현식과 일치하여 유효성 검사를 통과합니다. v1.A.B의 입력값은 정규 표현식과 일치하지 않아 유효성 검사에 실패합니다.

추가 세부 정보:

inputs:regex는 number 또는 boolean이 아닌 string type에서만 사용할 수 있습니다.
정규 표현식을 / 문자로 감싸지 마세요. 예를 들어, /regex.*/ 대신 regex.*를 사용합니다.
inputs:regex는 RE2를 사용하여 정규 표현식을 파싱합니다.
정규 표현식에 대한 입력값 유효성 검사는 변수 확장 전에 수행됩니다. 입력 텍스트에 변수 이름이 포함된 경우, 변수 값이 아닌 입력의 원시 값(변수 이름)이 유효성 검사됩니다.

`spec:inputs:rules`#

히스토리

GitLab 18.7에서 도입되었습니다.

다른 입력값의 값에 기반하여 입력값에 대한 조건부 options와 default 값을 정의하려면 spec:inputs:rules를 사용합니다.

키워드 유형: 헤더 키워드. spec은 설정 파일 상단의 헤더 섹션에 선언해야 합니다.

지원되는 값: 규칙 객체의 배열. 각 규칙은 다음을 가질 수 있습니다:

if: $[[ inputs.input-id ]] 문법을 사용하여 입력값을 확인하는 조건부 표현식.
options: 입력값에 허용되는 값의 배열.
default: 이 규칙이 일치할 때 입력값의 기본값. 사용자가 입력값에 자신의 값을 입력할 수 있도록 허용하려면 default: null을 사용합니다.

spec:inputs:rules 예시:

spec:
  inputs:
    environment:
      options: ['development', 'production']
      default: 'development'

    instance_type:
      description: 'VM instance size'
      rules:
        - if: $[[ inputs.environment ]] == 'development'
          options: ['small', 'medium']
          default: 'small'
        - if: $[[ inputs.environment ]] == 'production'
          options: ['large', 'xlarge']
          default: 'large'
---

deploy:
  script: echo "Deploying $[[ inputs.instance_type ]] instance"

이 예시에서, environment가 development이면 사용자는 small 또는 medium 인스턴스만 선택할 수 있습니다. environment가 production이면 large 또는 xlarge 인스턴스만 사용 가능합니다.

추가 세부 정보:

규칙은 순서대로 평가됩니다. 일치하는 if 조건이 있는 첫 번째 규칙이 사용됩니다.
if 조건이 없는 규칙은 다른 규칙이 일치하지 않을 때 대체 규칙으로 작동합니다.
대체 규칙은 최소 하나의 값으로 options를 정의해야 합니다.
options가 있는 모든 규칙은 options 목록에 있는 default 값을 정의해야 합니다.
동일한 입력값에 rules와 최상위 options 또는 default를 함께 사용할 수 없습니다.

관련 항목:

spec:inputs:rules로 조건부 입력 옵션 정의.

`spec:inputs:type`#

기본적으로 입력값은 문자열을 예상합니다. spec:inputs:type을 사용하여 입력값에 필요한 다른 유형을 설정합니다.

키워드 유형: 헤더 키워드. spec은 설정 파일 상단의 헤더 섹션에 선언해야 합니다.

지원되는 값: 다음 중 하나:

array: 입력값의 배열을 허용합니다.
string: 문자열 입력값을 허용합니다(정의되지 않은 경우 기본값).
number: 숫자 입력값만 허용합니다.
boolean: true 또는 false 입력값만 허용합니다.

spec:inputs:type 예시:

spec:
  inputs:
    job_name:
    website:
      type: string
    port:
      type: number
    available:
      type: boolean
    array_input:
      type: array
---
# The pipeline configuration would follow...

`spec:include`#

히스토리

GitLab 18.6에서 ci_file_inputs이라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화됩니다.
GitLab 18.9에서 일반 제공되었습니다. 기능 플래그 ci_file_inputs이 제거되었습니다.

spec:include를 사용하여 다른 파일에서 외부 입력 정의를 포함합니다. 여러 파이프라인 설정에서 입력 정의를 공유하고 재사용할 수 있습니다.

키워드 유형: 헤더 키워드. spec은 설정 파일 상단의 헤더 섹션에 선언해야 합니다.

지원되는 값: 포함 위치의 배열. local, remote, project include만 지원합니다.

spec:include 예시:

spec:
  include:
    - local: /shared-inputs.yml
  inputs:
    environment:
      default: production
---

deploy:
  script: echo "Deploying to $[[ inputs.environment ]]"

다른 소스의 여러 include:

spec:
  include:
    - local: /base-inputs.yml
    - remote: 'https://example.com/ci/common-inputs.yml'
    - project: 'my-group/shared-configs'
      ref: main
      file: '/ci/team-inputs.yml'
  inputs:
    environment:
      default: production
---

deploy:
  script: echo "Deploying to $[[ inputs.environment ]]"

추가 세부 정보:

CI/CD 컴포넌트에서 spec:include를 사용할 수 없습니다.
외부 입력 파일은 inputs 키만 포함해야 합니다. 다른 키는 유효성 검사 오류를 유발합니다.
외부 입력이 먼저 병합되고, 그 다음 인라인 입력이 적용됩니다.
인라인 입력은 포함된 입력과 동일한 이름을 가질 수 없습니다.
여러 입력 파일을 포함하면, 지정된 순서대로 병합됩니다.
local, remote, project include 유형을 지원합니다. template, component, 또는 artifact include는 지원하지 않습니다.

관련 항목:

외부 파일에서 입력값 사용.

`spec:component`#

히스토리

GitLab 18.6에서 ci_component_context_interpolation이라는 플래그와 함께 베타로 도입되었습니다. 기본적으로 활성화됩니다.
GitLab 18.7에서 일반 제공되었습니다. 기능 플래그 ci_component_context_interpolation이 제거되었습니다.

CI/CD 컴포넌트의 보간에 사용 가능한 컴포넌트 컨텍스트 데이터를 정의하려면 spec:component를 사용합니다.

컴포넌트 컨텍스트는 컴포넌트 이름, 버전, 커밋 SHA와 같은 컴포넌트 자체에 대한 메타데이터를 제공합니다. 이를 통해 컴포넌트 템플릿이 자체 메타데이터를 동적으로 참조할 수 있습니다.

컴포넌트 템플릿에서 컴포넌트 컨텍스트 값을 참조하려면 보간 형식 $[[ component.field-name ]]을 사용합니다.

키워드 유형: 헤더 키워드. spec은 설정 파일 상단의 헤더 섹션에 선언해야 합니다.

지원되는 값: 문자열 배열. 각 문자열은 다음 중 하나여야 합니다:

name: 컴포넌트 경로에 지정된 컴포넌트 이름.
sha: 컴포넌트의 커밋 SHA.
version: 카탈로그 리소스의 확인된 시맨틱 버전. 다음의 경우 null을 반환합니다:
- 컴포넌트가 카탈로그 리소스가 아닌 경우.
- 참조가 브랜치 이름이나 커밋 SHA인 경우(릴리스 버전이 아닌 경우).
reference: 컴포넌트 경로에서 @ 뒤에 지정된 원래 참조. 예를 들어, 1.0, ~latest, 브랜치 이름, 또는 커밋 SHA.

spec:component 예시:

spec:
  component: [name, version, reference]
  inputs:
    stage:
      default: build
---

build-image:
  stage: $[[ inputs.stage ]]
  image: registry.example.com/$[[ component.name ]]:$[[ component.version ]]
  script:
    - echo "Building with component version $[[ component.version ]]"
    - echo "Component reference: $[[ component.reference ]]"

추가 세부 정보:

version 필드는 다음을 사용할 때 실제 시맨틱 버전으로 확인됩니다:
- @1.0.0과 같은 전체 버전(returns 1.0.0)
- @1.0과 같은 부분 버전(최신 일치 버전 반환, 예: 1.0.2)
- @~latest(최신 버전 반환)
reference 필드는 항상 @ 뒤에 지정된 정확한 값을 반환합니다:
- @1.0은 1.0을 반환합니다(version은 1.0.2를 반환할 수 있습니다)
- @~latest는 ~latest를 반환합니다(version은 실제 버전 번호를 반환합니다)
- @abc123은 abc123을 반환합니다(version은 null을 반환합니다)

관련 항목:

컴포넌트에서 컴포넌트 컨텍스트 사용.

`spec:description`#

히스토리

GitLab 18.10에서 도입되었습니다.

컴포넌트에 대한 간략한 설명을 제공하려면 spec:description을 사용합니다. 설명은 입력값 테이블 위의 컴포넌트 세부 정보 페이지에서 CI/CD 카탈로그에 표시됩니다.

키워드 유형: 헤더 키워드. spec은 설정 파일 상단의 헤더 섹션에 선언해야 합니다.

지원되는 값: 컴포넌트를 설명하는 문자열.

spec:description 예시:

spec:
  description: "A description of the component visible to users in the CI/CD Catalog."
  inputs:
    stage:
      default: test
---
scan-job:
  stage: $[[ inputs.stage ]]
  script: ./run-scan.sh

Job 키워드#

다음 항목은 키워드를 사용하여 CI/CD 파이프라인을 설정하는 방법을 설명합니다.

`after_script`#

히스토리

취소된 job에 대한 after_script 명령어 실행이 GitLab 17.0에서 도입되었습니다.

job의 before_script와 script 섹션이 완료된 후 마지막으로 실행할 명령어 배열을 정의하려면 after_script를 사용합니다. after_script 명령어는 다음과 같은 경우에도 실행됩니다:

before_script 또는 script 섹션이 아직 실행 중인 동안 job이 취소된 경우.
job이 script_failure 유형의 실패로 실패하지만, 다른 실패 유형에서는 아닌 경우.

Job 설정과 기본 설정은 병합되지 않습니다. 파이프라인에 default:after_script가 정의되어 있고 job에도 after_script가 있는 경우, job 설정이 우선하고 기본 설정은 사용되지 않습니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값: 다음을 포함하는 배열:

단일 줄 명령어.
여러 줄로 분할된 긴 명령어.
YAML 앵커.

CI/CD 변수는 지원됩니다.

after_script 예시:

job:
  script:
    - echo "An example script section."
  after_script:
    - echo "Execute this command after the `script` section completes."

추가 세부 정보:

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분으로 하드코딩되어 있습니다.
job의 종료 코드에 영향을 미치지 않습니다. script 섹션이 성공하고 after_script가 타임아웃되거나 실패하면, job은 코드 0(Job Succeeded)으로 종료됩니다.
after_script와 함께 CI/CD job 토큰을 사용하는 알려진 문제가 있습니다. after_script 명령어에서 인증에 job 토큰을 사용할 수 있지만, job이 취소되면 토큰이 즉시 무효화됩니다. 자세한 내용은 이슈를 참조하세요.
타임아웃된 job의 경우:
- after_script 명령어는 기본적으로 실행되지 않습니다.
- job의 타임아웃을 초과하지 않는 적절한 RUNNER_SCRIPT_TIMEOUT과 RUNNER_AFTER_SCRIPT_TIMEOUT 값을 설정하여 after_script가 실행되도록 타임아웃 값을 설정할 수 있습니다.
최상위 레벨에서 after_script를 사용하지만 default 섹션에서는 사용하지 않는 것은 더 이상 사용되지 않습니다.

실행 타이밍 및 파일 포함:

after_script 명령어는 캐시 및 아티팩트 업로드 작업 전에 실행됩니다.

아티팩트 수집을 설정한 경우:
- after_script에서 생성하거나 수정한 파일이 아티팩트에 포함됩니다.
- after_script에서 변경한 내용이 캐시 업로드에 포함됩니다.
after_script가 지정된 캐시 또는 아티팩트 경로에 생성하거나 수정하는 모든 파일이 캡처되고 업로드됩니다. 이 타이밍을 다음과 같은 시나리오에 사용할 수 있습니다:
- 메인 스크립트 후 테스트 보고서 또는 커버리지 데이터 생성.
- 요약 파일 또는 로그 생성.
- 빌드 출력물 후처리.

다음 예시에서, 포함되지 않는 유일한 파일은 아티팩트 또는 캐시 업로드 단계 후에 생성하거나 수정된 파일입니다:

job:
  script:
    - echo "main" > output.txt
    - build_something

  after_script:
    - echo "modified in after_script" >> output.txt  # This WILL be in the artifact
    - generate_test_report > report.html            # This WILL be in the artifact

  artifacts:
    paths:
      - output.txt
      - report.html

  cache:
    paths:
      - output.txt  # Will include the "modified in after_script" line

자세한 내용은 job 실행 흐름을 참조하세요.

관련 항목:

모든 job 후에 실행해야 할 기본 명령어 배열을 정의하려면 default와 함께 after_script 사용.
job이 취소된 경우 after_script 명령어를 건너뛰도록 job을 설정할 수 있습니다.
0이 아닌 종료 코드를 무시할 수 있습니다.
job 로그를 쉽게 검토할 수 있도록 after_script에 색상 코드 사용.
사용자 정의 접을 수 있는 섹션 생성으로 job 로그 출력 간소화.
after_script에서 오류를 무시할 수 있습니다.

`allow_failure`#

allow_failure를 사용하여 job이 실패할 때 파이프라인이 계속 실행될지 여부를 결정합니다.

파이프라인이 후속 job을 계속 실행하도록 하려면 allow_failure: true를 사용합니다.
파이프라인이 후속 job 실행을 중지하도록 하려면 allow_failure: false를 사용합니다.

job이 실패해도 되는 경우(allow_failure: true) 주황색 경고([status_warning])가 job이 실패했음을 나타냅니다. 그러나 파이프라인은 성공하고 관련 커밋은 경고 없이 통과로 표시됩니다.

이 동일한 경고는 다음 경우에도 표시됩니다:

Stage의 다른 모든 job이 성공한 경우.
파이프라인의 다른 모든 job이 성공한 경우.

allow_failure의 기본값은:

수동 job의 경우 true.
rules 내에서 when: manual을 사용하는 job의 경우 false.
다른 모든 경우 false.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

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 Stage의 job이 시작되지 않습니다.
job2가 실패하면, deploy Stage의 job이 여전히 시작될 수 있습니다.

추가 세부 정보:

allow_failure를 rules의 서브키로 사용할 수 있습니다.
allow_failure: true가 설정된 경우, job은 항상 성공으로 간주되며, 이 job이 실패해도 when: on_failure가 있는 이후 job은 시작되지 않습니다.
수동 job에 allow_failure: false를 사용하여 블로킹 수동 job을 만들 수 있습니다. 블로킹된 파이프라인은 수동 job이 시작되어 성공적으로 완료될 때까지 이후 Stage의 어떤 job도 실행하지 않습니다.

`allow_failure:exit_codes`#

allow_failure:exit_codes를 사용하여 job이 실패해도 되는 경우를 제어합니다. 나열된 종료 코드의 경우 job은 allow_failure: true이고, 다른 종료 코드의 경우 allow_failure는 false입니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

단일 종료 코드.
종료 코드 배열.

allow_failure 예시:

test_job_1:
  script:
    - echo "Run a script that results in exit code 1. This job fails."
    - exit 1
  allow_failure:
    exit_codes: 137

test_job_2:
  script:
    - echo "Run a script that results in exit code 137. This job is allowed to fail."
    - exit 137
  allow_failure:
    exit_codes:
      - 137
      - 255

`artifacts`#

히스토리

GitLab Runner 18.1에서 업데이트되었습니다. 캐싱 프로세스 중에 이전 GitLab Runner 버전의 일부 엣지 케이스에서 발생했던 symlinks 추적이 더 이상 수행되지 않습니다.

job 아티팩트로 저장할 파일을 지정하려면 artifacts를 사용합니다. Job 아티팩트는 성공, 실패, 또는 항상 job에 첨부되는 파일 및 디렉토리 목록입니다.

아티팩트는 job이 완료된 후 GitLab으로 전송됩니다. 크기가 최대 아티팩트 크기보다 작으면 GitLab UI에서 다운로드할 수 있습니다.

기본적으로 이후 Stage의 job은 이전 Stage의 job이 생성한 모든 아티팩트를 자동으로 다운로드합니다. dependencies로 job의 아티팩트 다운로드 동작을 제어할 수 있습니다.

needs 키워드를 사용할 때, job은 needs 설정에 정의된 job의 아티팩트만 다운로드할 수 있습니다.

Job 아티팩트는 기본적으로 성공한 job에 대해서만 수집되며, 아티팩트는 캐시 후에 복원됩니다.

Job 설정과 기본 설정은 병합되지 않습니다. 파이프라인에 default:artifacts가 정의되어 있고 job에도 artifacts가 있는 경우, job 설정이 우선하고 기본 설정은 사용되지 않습니다.

아티팩트에 대해 더 읽어보기.

`artifacts:paths`#

경로는 프로젝트 디렉토리($CI_PROJECT_DIR)에 상대적이며 직접 외부에 링크할 수 없습니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

프로젝트 디렉토리에 상대적인 파일 경로 배열.
glob 패턴 및 doublestar.Glob 패턴을 사용하는 와일드카드를 사용할 수 있습니다.
GitLab Pages job의 경우:
- GitLab 17.10 이상에서, pages.publish 경로가 artifacts:paths에 자동으로 추가되므로 다시 지정할 필요가 없습니다.
- GitLab 17.10 이상에서, pages.publish 경로가 지정되지 않은 경우, public 디렉토리가 artifacts:paths에 자동으로 추가됩니다.

CI/CD 변수는 지원됩니다.

artifacts:paths 예시:

job:
  artifacts:
    paths:
      - binaries/
      - .config

이 예시는 .config와 binaries 디렉토리의 모든 파일로 아티팩트를 생성합니다.

추가 세부 정보:

artifacts:name과 함께 사용하지 않으면, 아티팩트 파일은 artifacts로 이름이 지정되며 다운로드 시 artifacts.zip이 됩니다.

관련 항목:

특정 job이 아티팩트를 가져오는 job을 제한하려면 dependencies를 참조하세요.
job 아티팩트 생성.

`artifacts:exclude`#

아티팩트 아카이브에 파일이 추가되지 않도록 하려면 artifacts:exclude를 사용합니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

프로젝트 디렉토리에 상대적인 파일 경로 배열.
glob 또는 doublestar.PathMatch 패턴을 사용하는 와일드카드를 사용할 수 있습니다.

artifacts:exclude 예시:

artifacts:
  paths:
    - binaries/
  exclude:
    - binaries/**/*.o

이 예시는 binaries/의 모든 파일을 저장하지만, binaries/의 하위 디렉토리에 있는 *.o 파일은 저장하지 않습니다.

추가 세부 정보:

artifacts:exclude 경로는 재귀적으로 검색되지 않습니다.
artifacts:untracked와 일치하는 파일은 artifacts:exclude를 사용하여 제외할 수도 있습니다.

관련 항목:

job 아티팩트에서 파일 제외.

`artifacts:expire_in`#

job 아티팩트가 만료되고 삭제되기 전에 저장되는 기간을 지정하려면 expire_in을 사용합니다. expire_in 설정은 다음에 영향을 미치지 않습니다:

프로젝트 수준 또는 인스턴스 전체에서 최신 job 아티팩트 유지가 비활성화된 경우를 제외하고, 최신 job의 아티팩트.

만료 후, 아티팩트는 기본적으로 매시간(cron job 사용) 삭제되며 더 이상 접근할 수 없습니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값: 만료 시간. 단위가 제공되지 않으면 시간은 초 단위입니다. 유효한 값은 다음과 같습니다:

'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에 저장될 때 시작됩니다. 만료 시간이 정의되지 않으면 인스턴스 전체 설정이 기본값입니다.
만료 날짜를 재정의하고 아티팩트가 자동으로 삭제되지 않도록 보호하려면:
- job 페이지에서 유지를 선택합니다.
- expire_in 값을 never로 설정합니다.
만료 시간이 너무 짧으면, 긴 파이프라인의 이후 Stage job이 이전 job의 만료된 아티팩트를 가져오려고 할 수 있습니다. 아티팩트가 만료되면, 가져오려는 job이 could not retrieve the needed artifacts 오류와 함께 실패합니다. 만료 시간을 더 길게 설정하거나, 이후 job에서 dependencies를 사용하여 만료된 아티팩트를 가져오지 않도록 합니다.
artifacts:expire_in은 GitLab Pages 배포에 영향을 미치지 않습니다. Pages 배포의 만료를 설정하려면 pages.expire_in을 사용합니다.

`artifacts:expose_as`#

머지 리퀘스트 UI에 아티팩트를 노출하려면 artifacts:expose_as 키워드를 사용합니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

아티팩트 다운로드 링크에 대해 머지 리퀘스트 UI에 표시할 이름. artifacts:paths와 함께 사용해야 합니다.

artifacts:expose_as 예시:

test:
  script: ["echo 'test' > file.txt"]
  artifacts:
    expose_as: 'artifact 1'
    paths: ['file.txt']

추가 세부 정보:

job당 expose_as를 한 번만 사용할 수 있으며, 머지 리퀘스트당 최대 10개의 job이 있습니다.
glob 패턴은 지원되지 않습니다.
아티팩트는 항상 GitLab으로 전송됩니다. artifacts:paths 값이 다음인 경우를 제외하고 UI에 표시됩니다:
- CI/CD 변수를 사용합니다.
- 디렉토리를 정의하지만 /로 끝나지 않습니다. 예를 들어, directory/는 artifacts:expose_as와 함께 작동하지만 directory는 작동하지 않습니다.
artifacts:paths에 단일 파일만 포함된 경우, 링크는 파일을 직접 엽니다. 다른 모든 경우, 링크는 아티팩트 브라우저를 엽니다.
링크된 파일은 기본적으로 다운로드됩니다. GitLab Pages가 활성화된 경우, 일부 아티팩트 파일 확장자를 브라우저에서 직접 미리 볼 수 있습니다. 자세한 내용은 아티팩트 아카이브 내용 탐색을 참조하세요.

관련 항목:

머지 리퀘스트 UI에 job 아티팩트 노출.

`artifacts:name`#

생성된 아티팩트 아카이브의 이름을 정의하려면 artifacts:name 키워드를 사용합니다. 모든 아카이브에 대해 고유한 이름을 지정할 수 있습니다.

정의되지 않은 경우, 기본 이름은 artifacts이며 다운로드 시 artifacts.zip이 됩니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

아티팩트 아카이브의 이름. CI/CD 변수는 지원됩니다. artifacts:paths와 함께 사용해야 합니다.

artifacts:name 예시:

현재 job 이름으로 아카이브를 생성하려면:

job:
  artifacts:
    name: "job1-artifacts-file"
    paths:
      - binaries/

관련 항목:

CI/CD 변수를 사용하여 아티팩트 설정 정의

`artifacts:public`#

히스토리

GitLab 15.10에서 업데이트되었습니다. 15.10 이전에 artifacts:public으로 생성된 아티팩트는 이 업데이트 후에도 비공개로 유지된다는 보장이 없습니다.
GitLab 16.7에서 일반 제공되었습니다. 기능 플래그 non_public_artifacts가 제거되었습니다.

Note

artifacts:public은 이제 더 많은 옵션을 가진 artifacts:access로 대체되었습니다.

공개 파이프라인의 job 아티팩트를 익명 사용자 또는 Guest 및 Reporter 역할이 GitLab UI 및 API로 다운로드할 수 있는지 여부를 제어하려면 artifacts:public을 사용합니다.

Warning

이 옵션은 GitLab UI 및 API 접근에만 영향을 미칩니다. job 토큰을 사용하는 CI/CD job은 이 설정에 관계없이 러너 API로 아티팩트에 접근할 수 있습니다. job 토큰 접근을 제한하려면 프로젝트의 CI/CD 가시성 설정을 프로젝트 멤버만으로 설정합니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

true(기본값): 공개 파이프라인의 job 아티팩트는 익명 사용자 또는 Guest 및 Reporter 역할을 포함한 누구나 다운로드할 수 있습니다.
false: job의 아티팩트는 Developer, Maintainer, 또는 Owner 역할을 가진 사용자만 다운로드할 수 있습니다.

artifacts:public 예시:

job:
  artifacts:
    public: false

`artifacts:access`#

히스토리

GitLab 16.11에서 도입되었습니다.
maintainer 옵션이 GitLab 18.4에서 도입되었습니다.

GitLab UI 또는 API에서 job 아티팩트에 접근할 수 있는 사람을 결정하려면 artifacts:access를 사용합니다. 이 옵션은 아티팩트를 다운스트림 파이프라인으로 전달하는 것을 방지하지 않습니다.

동일한 job에서 artifacts:public과 artifacts:access를 사용할 수 없습니다.

Warning

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

all(기본값): 공개 파이프라인의 job 아티팩트는 익명, guest, reporter 사용자를 포함한 누구나 다운로드할 수 있습니다.
developer: job의 아티팩트는 Developer, Maintainer, 또는 Owner 역할을 가진 사용자만 다운로드할 수 있습니다.
maintainer: job의 아티팩트는 Maintainer 또는 Owner 역할을 가진 사용자만 다운로드할 수 있습니다.
none: 누구도 job의 아티팩트를 다운로드할 수 없습니다.

artifacts:access 예시:

job:
  artifacts:
    access: 'developer'

추가 세부 정보:

artifacts:access는 모든 artifacts:reports에도 영향을 미치므로, 보고서용 아티팩트에 대한 접근도 제한할 수 있습니다.

`artifacts:reports`#

job에 포함된 템플릿이 생성한 아티팩트를 수집하려면 artifacts:reports를 사용합니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

사용 가능한 아티팩트 보고서 유형 목록 참조.

artifacts:reports 예시:

rspec:
  stage: test
  script:
    - bundle install
    - rspec --format RspecJunitFormatter --out rspec.xml
  artifacts:
    reports:
      junit: rspec.xml

추가 세부 정보:

자식 파이프라인의 아티팩트를 사용하여 상위 파이프라인에서 보고서를 결합하는 것은 지원되지 않습니다. 지원 추가 진행 상황은 이 이슈에서 추적합니다.
보고서 출력 파일을 탐색하고 다운로드할 수 있으려면 artifacts:paths 키워드를 포함합니다. 이렇게 하면 아티팩트가 두 번 업로드되고 저장됩니다.
artifacts: reports로 생성된 아티팩트는 job 결과(성공 또는 실패)에 관계없이 항상 업로드됩니다. artifacts:expire_in을 사용하여 아티팩트의 만료 날짜를 설정할 수 있습니다.

`artifacts:untracked`#

artifacts:untracked를 사용하여 모든 Git 추적되지 않은 파일을 아티팩트로 추가합니다(artifacts:paths에 정의된 경로와 함께). artifacts:untracked는 리포지터리의 .gitignore 설정을 무시하므로, .gitignore와 일치하는 아티팩트가 포함됩니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

true 또는 false(정의되지 않은 경우 기본값).

artifacts:untracked 예시:

모든 Git 추적되지 않은 파일 저장:

job:
  artifacts:
    untracked: true

관련 항목:

추적되지 않은 파일을 아티팩트에 추가.

`artifacts:when`#

job 실패 시 또는 실패에도 불구하고 아티팩트를 업로드하려면 artifacts:when을 사용합니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

on_success(기본값): job이 성공할 때만 아티팩트를 업로드합니다.
on_failure: job이 실패할 때만 아티팩트를 업로드합니다.
always: 항상 아티팩트를 업로드합니다(job 타임아웃 제외). 예를 들어, 실패한 테스트 문제를 해결하는 데 필요한 아티팩트를 업로드할 때.

artifacts:when 예시:

job:
  artifacts:
    when: on_failure

추가 세부 정보:

artifacts:reports로 생성된 아티팩트는 job 결과(성공 또는 실패)에 관계없이 항상 업로드됩니다. artifacts:when은 이 동작을 변경하지 않습니다.

`before_script`#

각 job의 script 명령어 전에, 하지만 아티팩트가 복원된 후에 실행해야 할 명령어 배열을 정의하려면 before_script를 사용합니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값: 다음을 포함하는 배열:

단일 줄 명령어.
여러 줄로 분할된 긴 명령어.
YAML 앵커.

CI/CD 변수는 지원됩니다.

before_script 예시:

job:
  before_script:
    - echo "Execute this command before any 'script:' commands."
  script:
    - echo "This command executes after the job's 'before_script' commands."

추가 세부 정보:

before_script에 지정한 스크립트는 메인 script에 지정한 스크립트와 연결됩니다. 결합된 스크립트가 단일 셸에서 함께 실행됩니다.
최상위 레벨에서 before_script를 사용하지만 default 섹션에서는 사용하지 않는 것은 더 이상 사용되지 않습니다.

관련 항목:

모든 job의 script 명령어 전에 실행해야 할 기본 명령어 배열을 정의하려면 default와 함께 before_script 사용.
- Job 설정과 기본 설정은 병합되지 않습니다. 파이프라인에 default:before_script가 정의되어 있고 job에도 before_script가 있는 경우, job 설정이 우선하고 기본 설정은 사용되지 않습니다.
0이 아닌 종료 코드를 무시할 수 있습니다.
job 로그를 쉽게 검토할 수 있도록 before_script에 색상 코드 사용.
사용자 정의 접을 수 있는 섹션 생성으로 job 로그 출력 간소화.

`cache`#

히스토리

GitLab 15.0에서 도입되었습니다. 캐시는 보호된 브랜치와 보호되지 않은 브랜치 간에 공유되지 않습니다.
GitLab Runner 18.1에서 업데이트되었습니다. 캐싱 프로세스 중에 이전 GitLab Runner 버전의 일부 엣지 케이스에서 발생했던 symlinks 추적이 더 이상 수행되지 않습니다.

job 간에 캐시할 파일 및 디렉토리 목록을 지정하려면 cache를 사용합니다. 로컬 작업 복사본에 있는 경로만 사용할 수 있습니다.

캐시는:

파이프라인과 job 간에 공유됩니다.
기본적으로 보호된 브랜치와 보호되지 않은 브랜치 간에 공유되지 않습니다.
아티팩트 전에 복원됩니다.
최대 4개의 다른 캐시로 제한됩니다.

예를 들어 다음을 재정의하기 위해 특정 job에 대한 캐싱을 비활성화할 수 있습니다:

default로 정의된 기본 캐시.
include로 추가된 job 설정.

Job 설정과 기본 설정은 병합되지 않습니다. 파이프라인에 default:cache가 정의되어 있고 job에도 cache가 있는 경우, job 설정이 우선하고 기본 설정은 사용되지 않습니다.

캐시에 대한 자세한 내용은 GitLab CI/CD에서의 캐싱을 참조하세요.

최상위 레벨에서 cache를 사용하지만 default 섹션에서는 사용하지 않는 것은 더 이상 사용되지 않습니다.

`cache:paths`#

캐시할 파일 또는 디렉토리를 선택하려면 cache:paths 키워드를 사용합니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

프로젝트 디렉토리($CI_PROJECT_DIR)에 상대적인 경로 배열. glob 및 doublestar.Glob 패턴을 사용하는 와일드카드를 사용할 수 있습니다.

CI/CD 변수가 지원됩니다.

cache:paths 예시:

.apk로 끝나는 binaries의 모든 파일과 .config 파일을 캐시합니다:

rspec:
  script:
    - echo "This job uses a cache."
  cache:
    key: binaries-cache
    paths:
      - binaries/*.apk
      - .config

추가 세부 정보:

cache:paths 키워드는 추적되지 않은 파일이나 .gitignore 파일에 있는 파일도 포함합니다.

관련 항목:

더 많은 cache:paths 예시는 CI/CD 캐싱 예시를 참조하세요.

`cache:key`#

각 캐시에 고유한 식별 키를 제공하려면 cache:key 키워드를 사용합니다. 동일한 캐시 키를 사용하는 모든 job은 다른 파이프라인을 포함하여 동일한 캐시를 사용합니다.

설정되지 않으면, 기본 키는 default입니다. cache 키워드가 있지만 cache:key가 없는 모든 job은 default 캐시를 공유합니다.

cache: paths와 함께 사용해야 하며, 그렇지 않으면 아무것도 캐시되지 않습니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

문자열.
사전 정의된 CI/CD 변수.
두 가지의 조합.

cache:key 예시:

cache-job:
  script:
    - echo "This job uses a cache."
  cache:
    key: binaries-cache-$CI_COMMIT_REF_SLUG
    paths:
      - binaries/

추가 세부 정보:

Windows Batch를 사용하여 셸 스크립트를 실행하는 경우 $를 %로 바꿔야 합니다. 예: key: %CI_COMMIT_REF_SLUG%
cache:key 값에는 다음을 포함할 수 없습니다:
- / 문자 또는 동등한 URI 인코딩 %2F.
- . 문자만 있는 경우(임의 수), 또는 동등한 URI 인코딩 %2E.
캐시는 job 간에 공유되므로, 다른 job에 대해 다른 경로를 사용하는 경우 다른 cache:key도 설정해야 합니다. 그렇지 않으면 캐시 내용이 덮어씌워질 수 있습니다.

관련 항목:

지정된 cache:key를 찾을 수 없는 경우 사용할 대체 캐시 키를 지정할 수 있습니다.
단일 job에서 여러 캐시 키를 사용할 수 있습니다.
더 많은 cache:key 예시는 CI/CD 캐싱 예시를 참조하세요.

`cache:key:files`#

지정된 파일의 내용이 변경될 때 새 캐시 키를 생성하려면 cache:key:files를 사용합니다. 내용이 변경되지 않으면, 캐시 키는 브랜치와 파이프라인에 걸쳐 일관성을 유지합니다. 캐시를 재사용하고 덜 자주 재빌드할 수 있어 후속 파이프라인 실행이 빨라집니다.

키워드 유형: Job 키워드. job의 일부로 또는 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을 사용하는 향후 job 실행은 종속성을 재빌드하는 대신 새 캐시를 사용합니다.

추가 세부 정보:

캐시 key는 나열된 파일의 내용에서 계산된 SHA입니다. 파일이 없으면 키 계산에서 무시됩니다. 지정된 파일 중 아무것도 없으면 대체 키는 default입니다.
**/package.json과 같은 와일드카드 패턴을 사용할 수 있습니다. 캐시 키에 허용되는 경로 또는 패턴 수를 늘리기 위한 이슈가 있습니다.

`cache:key:files_commits`#

지정된 파일에 대한 최신 커밋이 변경될 때 새 캐시 키를 생성하려면 cache:key:files_commits를 사용합니다. cache:key:files_commits 캐시 키는 파일 내용이 동일하더라도 지정된 파일에 새 커밋이 있을 때마다 변경됩니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

최대 두 개의 파일 경로 또는 패턴 배열.

cache:key:files_commits 예시:

cache-job:
  script:
    - echo "This job uses a commit-based cache."
  cache:
    key:
      files_commits:
        - package.json
        - yarn.lock
    paths:
      - node_modules

이 예시는 package.json과 yarn.lock의 커밋 기록을 기반으로 캐시를 생성합니다. 이러한 파일의 커밋 기록이 변경되면 새 캐시 키가 계산되고 새 캐시가 생성됩니다.

추가 세부 정보:

캐시 key는 각 지정된 파일의 가장 최근 커밋에서 계산된 SHA입니다.
파일이 없으면 키 계산에서 무시됩니다.
지정된 파일 중 아무것도 없으면 대체 키는 default입니다.
동일한 캐시 설정에서 cache:key:files와 함께 사용할 수 없습니다.

`cache:key:prefix`#

cache:key:prefix를 사용하여 cache:key:files에 대해 계산된 SHA와 접두사를 결합합니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

문자열.
사전 정의된 CI/CD 변수.
두 가지의 조합.

cache:key:prefix 예시:

rspec:
  script:
    - echo "This rspec job uses a cache."
  cache:
    key:
      files:
        - Gemfile.lock
      prefix: $CI_JOB_NAME
    paths:
      - vendor/ruby

예를 들어, $CI_JOB_NAME의 prefix를 추가하면 키가 rspec-feef9576d21ee9b6a32e30c5c79d0a0ceb68d1e5처럼 됩니다. 브랜치가 Gemfile.lock을 변경하면 해당 브랜치는 cache:key:files에 대한 새 SHA 체크섬을 가집니다. 새 캐시 키가 생성되고 해당 키에 대한 새 캐시가 생성됩니다. Gemfile.lock을 찾을 수 없는 경우, 접두사가 default에 추가되므로 예시의 키는 rspec-default가 됩니다.

추가 세부 정보:

cache:key:files의 파일이 커밋에서 변경되지 않은 경우, 접두사가 default 키에 추가됩니다.

`cache:untracked`#

Git 리포지터리에서 추적되지 않은 모든 파일을 캐시하려면 untracked: true를 사용합니다. 추적되지 않은 파일에는 다음이 포함됩니다:

.gitignore 설정으로 인해 무시된 파일.
생성되었지만 git add로 체크아웃에 추가되지 않은 파일.

job이 다음을 다운로드하는 경우 추적되지 않은 파일 캐싱이 예상보다 큰 캐시를 생성할 수 있습니다:

gem이나 node 모듈과 같이 일반적으로 추적되지 않은 종속성.
다른 job의 아티팩트. 아티팩트에서 추출된 파일은 기본적으로 추적되지 않습니다.

키워드 유형: Job 키워드. job의 일부로 또는 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/
```
이 예시에서 job은 리포지터리의 모든 추적되지 않은 파일과 binaries/의 모든 파일을 캐시합니다. binaries/에 추적되지 않은 파일이 있으면, 두 키워드 모두에 포함됩니다.

`cache:unprotect`#

히스토리

GitLab 15.8에서 도입되었습니다.

보호된 브랜치와 보호되지 않은 브랜치 간에 캐시를 공유하도록 설정하려면 cache:unprotect를 사용합니다.

Warning

true로 설정하면, 보호된 브랜치에 대한 접근 권한이 없는 사용자가 보호된 브랜치가 사용하는 캐시 키에 읽고 쓸 수 있습니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

true 또는 false(기본값).

cache:unprotect 예시:

rspec:
  script: test
  cache:
    unprotect: true

`cache:when`#

job 상태에 따라 캐시를 저장할 시기를 정의하려면 cache:when을 사용합니다.

cache: paths와 함께 사용해야 하며, 그렇지 않으면 아무것도 캐시되지 않습니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

on_success(기본값): job이 성공할 때만 캐시를 저장합니다.
on_failure: job이 실패할 때만 캐시를 저장합니다.
always: 항상 캐시를 저장합니다.

cache:when 예시:

rspec:
  script: rspec
  cache:
    paths:
      - rspec/
    when: 'always'

이 예시는 job이 실패하든 성공하든 캐시를 저장합니다.

`cache:policy`#

캐시의 업로드 및 다운로드 동작을 변경하려면 cache:policy 키워드를 사용합니다. 기본적으로 job은 시작될 때 캐시를 다운로드하고 job이 끝날 때 변경 사항을 캐시에 업로드합니다. 이 캐싱 스타일은 pull-push 정책(기본값)입니다.

job이 시작될 때만 캐시를 다운로드하지만 job이 완료될 때 변경 사항을 업로드하지 않도록 설정하려면 cache:policy:pull을 사용합니다.

job이 완료될 때만 캐시를 업로드하지만 job이 시작될 때 캐시를 다운로드하지 않도록 설정하려면 cache:policy:push를 사용합니다.

동일한 캐시를 사용하는 많은 job이 병렬로 실행될 때 pull 정책을 사용합니다. 이 정책은 job 실행 속도를 높이고 캐시 서버의 부하를 줄입니다. push 정책으로 job을 사용하여 캐시를 빌드할 수 있습니다.

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..."

관련 항목:

변수를 사용하여 job의 캐시 정책 제어.

`cache:fallback_keys`#

cache:key에 대한 캐시를 찾을 수 없는 경우 캐시를 복원하려고 시도할 키 목록을 지정하려면 cache:fallback_keys를 사용합니다. 캐시는 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를 사용하여 job 출력에서 코드 커버리지를 추출하는 방법을 설정합니다. job 출력의 최소 한 줄이 정규 표현식과 일치하면 UI에 커버리지가 표시됩니다.

일치에서 코드 커버리지 값을 추출하기 위해 GitLab은 이 더 작은 정규 표현식을 사용합니다: \d+(?:\.\d+)?.

지원되는 값:

RE2 정규 표현식. /로 시작하고 끝나야 합니다. 커버리지 번호와 일치해야 합니다. 주변 텍스트와도 일치할 수 있으므로, 정확한 번호를 캡처하기 위해 정규 표현식 문자 그룹을 사용할 필요가 없습니다. RE2 문법을 사용하므로 모든 그룹은 비캡처여야 합니다.

coverage 예시:

job1:
  script: rspec
  coverage: '/Code coverage: \d+(?:\.\d+)?/'

이 예시에서:

GitLab은 정규 표현식과 일치하는 job 로그를 확인합니다. Code coverage: 67.89% of lines covered와 같은 줄이 일치합니다.
GitLab은 정규 표현식과 일치하는 항목을 찾기 위해 일치하는 단편을 확인합니다: \d+(?:\.\d+)?. 샘플 정규 표현식은 67.89의 코드 커버리지와 일치할 수 있습니다.

추가 세부 정보:

코드 커버리지에서 정규 표현식 예시를 찾을 수 있습니다.
job 출력에 일치하는 줄이 두 개 이상 있으면 마지막 줄이 사용됩니다(역방향 검색의 첫 번째 결과).
단일 줄에 여러 일치가 있으면 마지막 일치에서 커버리지 번호가 검색됩니다.
일치하는 단편에서 여러 커버리지 번호가 발견되면 첫 번째 번호가 사용됩니다.
선행 0이 제거됩니다.
자식 파이프라인의 커버리지 출력은 기록되거나 표시되지 않습니다. 자세한 내용은 관련 이슈를 확인하세요.

`dast_configuration`#

CI/CD 설정에서 사용할 사이트 프로필 및 스캐너 프로필을 지정하려면 dast_configuration 키워드를 사용합니다. 두 프로필 모두 프로젝트에 먼저 생성되어 있어야 합니다. job의 Stage는 dast여야 합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값: site_profile과 scanner_profile 각각 하나씩.

job에서 사용할 사이트 프로필을 지정하려면 site_profile을 사용합니다.
job에서 사용할 스캐너 프로필을 지정하려면 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 job은 include 키워드로 추가된 dast 설정을 확장하여 특정 사이트 프로필과 스캐너 프로필을 선택합니다.

추가 세부 정보:

사이트 프로필 또는 스캐너 프로필에 포함된 설정은 DAST 템플릿에 포함된 설정보다 우선합니다.

관련 항목:

`dependencies`#

아티팩트를 가져올 특정 job 목록을 정의하려면 dependencies 키워드를 사용합니다. 지정된 job은 모두 이전 Stage에 있어야 합니다. 어떤 아티팩트도 다운로드하지 않도록 job을 설정할 수도 있습니다.

dependencies가 job에 정의되지 않으면, 이전 Stage의 모든 job이 종속된 것으로 간주되고 job은 해당 job에서 모든 아티팩트를 가져옵니다.

동일한 Stage의 job에서 아티팩트를 가져오려면 needs:artifacts를 사용해야 합니다. 동일한 job에서 dependencies와 needs를 결합하지 않아야 합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

아티팩트를 가져올 job 이름.
어떤 아티팩트도 다운로드하지 않도록 job을 설정하는 빈 배열([]).

dependencies 예시:

build mac:
  stage: build
  script: make build:mac
  artifacts:
    paths:
      - binaries/

build linux:
  stage: build
  script: make build:linux
  artifacts:
    paths:
      - binaries/

test mac:
  stage: test
  script: make test:mac
  dependencies:
    - build mac

test linux:
  stage: test
  script: make test:linux
  dependencies:
    - build linux

deploy:
  stage: deploy
  script: make deploy
  environment: production

이 예시에서, 두 job에 아티팩트가 있습니다: build mac와 build linux. test mac이 실행되면, build mac의 아티팩트가 빌드 컨텍스트에서 다운로드되고 추출됩니다. test linux와 build linux의 아티팩트도 마찬가지입니다.

deploy job은 Stage 우선 순위로 인해 모든 이전 job에서 아티팩트를 다운로드합니다.

추가 세부 정보:

job 상태는 중요하지 않습니다. job이 실패하거나 트리거되지 않은 수동 job이어도 오류가 발생하지 않습니다.
종속된 job의 아티팩트가 만료되거나 삭제되면 job이 실패합니다.

`environment`#

job이 배포하는 환경을 정의하려면 environment를 사용합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값: job이 배포하는 환경의 이름, 다음 형식 중 하나:

문자, 숫자, 공백 및 다음 문자를 포함하는 일반 텍스트: -, _, /, $, {, }.
사전 정의된, 프로젝트, 그룹, 인스턴스 또는 .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이지만 원하는 이름을 사용할 수 있습니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값: job이 배포하는 환경의 이름, 다음 형식 중 하나:

문자, 숫자, 공백 및 다음 문자를 포함하는 일반 텍스트: -, _, /, $, {, }.
사전 정의된, 프로젝트, 그룹, 인스턴스 또는 .gitlab-ci.yml 파일에 정의된 변수를 포함하는 CI/CD 변수. 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과 같은 일반 텍스트.
사전 정의된, 프로젝트, 그룹, 인스턴스 또는 .gitlab-ci.yml 파일에 정의된 변수를 포함하는 CI/CD 변수. script 섹션에서 정의된 변수는 사용할 수 없습니다.

environment:url 예시:

deploy to production:
  stage: deploy
  script: git push production HEAD:main
  environment:
    name: production
    url: https://prod.example.com

추가 세부 정보:

job이 완료되면, 머지 리퀘스트, 환경 또는 배포 페이지에서 버튼을 선택하여 URL에 접근할 수 있습니다.

`environment:on_stop`#

환경 종료(중지)는 environment 아래에 정의된 on_stop 키워드로 달성할 수 있습니다. 환경을 닫기 위해 실행되는 다른 job을 선언합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

추가 세부 정보:

자세한 내용과 예시는 environment:action을 참조하세요.

`environment:action`#

job이 환경과 어떻게 상호작용하는지 지정하려면 action 키워드를 사용합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값: 다음 키워드 중 하나:

값	설명
`start`	기본값. job이 환경을 시작함을 나타냅니다. job이 시작된 후 배포가 생성됩니다.
`prepare`	job이 환경을 준비하기만 한다는 것을 나타냅니다. 배포를 트리거하지 않습니다. 환경 준비에 대한 자세한 내용.
`stop`	job이 환경을 중지함을 나타냅니다. 환경 중지에 대한 자세한 내용.
`verify`	job이 환경을 확인하기만 한다는 것을 나타냅니다. 배포를 트리거하지 않습니다. 환경 확인에 대한 자세한 내용.
`access`	job이 환경에만 접근한다는 것을 나타냅니다. 배포를 트리거하지 않습니다. 환경 접근에 대한 자세한 내용.

environment:action 예시:

stop_review_app:
  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`#

히스토리

CI/CD 변수 지원이 GitLab 15.4에서 도입되었습니다.
GitLab 17.7에서 prepare, access, verify 환경 액션을 지원하도록 업데이트되었습니다.

auto_stop_in 키워드는 환경의 수명을 지정합니다. 환경이 만료되면, GitLab이 자동으로 중지합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값: 자연어로 작성된 기간. 예를 들어, 이것들은 모두 동일합니다:

168 hours
7 days
one week
never

CI/CD 변수는 지원됩니다.

environment:auto_stop_in 예시:

review_app:
  script: deploy-review-app
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    auto_stop_in: 1 day

review_app의 환경이 생성되면, 환경의 수명이 1 day로 설정됩니다. 리뷰 앱이 배포될 때마다 해당 수명도 1 day로 재설정됩니다.

auto_stop_in 키워드는 stop을 제외한 모든 환경 액션에 사용할 수 있습니다. 일부 액션은 환경에 대한 예약된 중지 시간을 재설정하는 데 사용할 수 있습니다. 자세한 내용은 준비 또는 확인 목적으로 환경 접근을 참조하세요.

관련 항목:

환경 자동 중지 문서.

`environment:kubernetes`#

히스토리

agent 키워드가 GitLab 17.6에서 도입되었습니다.
namespace 및 flux_resource_path 키워드가 GitLab 17.7에서 도입되었습니다.
namespace 및 flux_resource_path 키워드가 GitLab 18.4에서 더 이상 사용되지 않습니다.
dashboard:namespace 및 dashboard:flux_resource_path 키워드가 GitLab 18.4에서 도입되었습니다.

kubernetes 키워드를 사용하여 환경에 대한 Kubernetes 대시보드와 GitLab 관리 Kubernetes 리소스를 구성합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

agent: Kubernetes용 GitLab 에이전트를 지정하는 문자열. 형식은 path/to/agent/project:agent-name입니다. 에이전트가 파이프라인을 실행하는 프로젝트에 연결되어 있으면 $CI_PROJECT_PATH:agent-name을 사용하세요.
dashboard:namespace: 환경이 배포된 Kubernetes 네임스페이스를 나타내는 문자열. 네임스페이스는 agent 키워드와 함께 설정해야 합니다. namespace는 더 이상 사용되지 않습니다.
dashboard:flux_resource_path: HelmRelease 같은 Flux 리소스의 전체 경로를 나타내는 문자열. Flux 리소스는 agent 및 dashboard:namespace 키워드와 함께 설정해야 합니다. flux_resource_path는 더 이상 사용되지 않습니다.
managed_resources: enabled 키워드가 있는 해시로, 환경에 대한 GitLab 관리 Kubernetes 리소스를 구성합니다.
- managed_resources:enabled: GitLab 관리 Kubernetes 리소스가 환경에서 활성화되어 있는지 여부를 나타내는 불리언 값.
dashboard: 환경에 대한 Kubernetes 대시보드를 구성하는 dashboard:namespace 및 dashboard:flux_resource_path 키워드가 있는 해시.

environment:kubernetes 예시:

deploy:
  stage: deploy
  script: make deploy-app
  environment:
    name: production
    kubernetes:
      agent: path/to/agent/project:agent-name
      dashboard:
        namespace: my-namespace
        flux_resource_path: helm.toolkit.fluxcd.io/v2/namespaces/flux-system/helmreleases/helm-release-resource

관리 리소스를 비활성화하는 경우의 environment:kubernetes 예시:

deploy:
  stage: deploy
  script: make deploy-app
  environment:
    name: production
    kubernetes:
      agent: path/to/agent/project:agent-name
      managed_resources:
        enabled: false
      dashboard:
        namespace: my-namespace
        flux_resource_path: helm.toolkit.fluxcd.io/v2/namespaces/flux-system/helmreleases/helm-release-resource

이 구성은 다음을 수행합니다:

deploy job을 production 환경에 배포하도록 설정합니다.
agent-name이라는 에이전트를 환경과 연결합니다.
네임스페이스 my-namespace와 helm.toolkit.fluxcd.io/v2/namespaces/flux-system/helmreleases/helm-release-resource로 설정된 flux_resource_path로 환경에 대한 Kubernetes 대시보드를 구성합니다.

추가 세부 정보:

대시보드를 사용하려면 Kubernetes용 GitLab 에이전트를 설치하고 환경의 프로젝트 또는 상위 그룹에 대해 user_access를 구성해야 합니다.
job을 실행하는 사용자는 클러스터 에이전트에 액세스할 수 있는 권한이 있어야 합니다. 그렇지 않으면 대시보드는 agent, namespace, flux_resource_path 속성을 무시합니다.
agent만 설정하려면 namespace를 설정할 필요가 없으며 flux_resource_path는 설정할 수 없습니다. 하지만 이 구성은 Kubernetes 대시보드에서 클러스터의 모든 네임스페이스를 나열합니다.

`environment:deployment_tier`#

히스토리

CI/CD 변수 지원이 GitLab 18.5에서 추가되었습니다.

deployment_tier 키워드를 사용하여 배포 환경의 계층을 지정합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값: 다음 중 하나:

production
staging
testing
development
other
CI/CD 변수 (사전 정의된 변수, 프로젝트, 그룹, 인스턴스 변수, 또는 .gitlab-ci.yml 파일에 정의된 변수 포함). script 섹션에서 정의된 변수는 사용할 수 없습니다.

environment:deployment_tier 예시:

deploy:
  script: echo
  environment:
    name: customer-portal
    deployment_tier: production

추가 세부 정보:

이 job 정의에서 생성된 환경에는 이 값을 기반으로 계층이 할당됩니다.
이 값이 나중에 추가된 경우 기존 환경의 계층은 업데이트되지 않습니다. 기존 환경의 계층은 Environments API를 통해 업데이트해야 합니다.

관련 항목:

환경의 배포 계층.

동적 환경#

CI/CD 변수를 사용하여 환경 이름을 동적으로 지정합니다.

예시:

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로 접근할 수 있습니다.

일반적인 사용 사례는 브랜치를 위한 동적 환경을 생성하고 리뷰 앱으로 사용하는 것입니다. 리뷰 앱을 사용하는 예시는 https://gitlab.com/gitlab-examples/review-apps-nginx/에서 볼 수 있습니다.

`extends`#

extends를 사용하여 구성 섹션을 재사용합니다. 이는 YAML 앵커의 대안이며 좀 더 유연하고 읽기 쉽습니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

파이프라인에 있는 다른 job의 이름.
파이프라인에 있는 다른 job 이름의 목록(배열).

extends 예시:

.tests:
  stage: test
  image: ruby:3.0

rspec:
  extends: .tests
  script: rake rspec

rubocop:
  extends: .tests
  script: bundle exec rubocop

이 예시에서 rspec job은 .tests 템플릿 job의 구성을 사용합니다. 파이프라인을 생성할 때 GitLab은 다음을 수행합니다:

키를 기반으로 역방향 깊은 병합을 수행합니다.
.tests 내용을 rspec job과 병합합니다.
키 값은 병합하지 않습니다.

결합된 구성은 다음 job과 동일합니다:

rspec:
  stage: test
  image: ruby:3.0
  script: rake rspec

rubocop:
  stage: test
  image: ruby:3.0
  script: bundle exec rubocop

추가 세부 정보:

extends에 여러 부모를 사용할 수 있습니다.
extends 키워드는 최대 11단계 상속을 지원하지만 세 단계를 초과하여 사용하는 것은 피하는 것이 좋습니다.
이전 예시에서 .tests는 히든 job이지만 일반 job의 구성도 확장할 수 있습니다.

관련 항목:

extends를 사용하여 구성 섹션 재사용.
extends를 사용하여 포함된 구성 파일에서 구성 재사용.

`hooks`#

히스토리

GitLab 15.6에서 ci_hooks_pre_get_sources_script라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
GitLab 15.10에서 일반 공개되었습니다. 기능 플래그 ci_hooks_pre_get_sources_script가 제거되었습니다.

hooks를 사용하여 Git 리포지터리를 가져오기 전과 같이 job 실행의 특정 단계에서 러너에서 실행할 명령 목록을 지정합니다.

job 구성과 기본 구성은 함께 병합되지 않습니다. 파이프라인에 default:hooks가 정의되어 있고 job에도 hooks가 있는 경우 job 구성이 우선하며 기본 구성은 사용되지 않습니다.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

hooks와 명령의 해시. 사용 가능한 hooks: 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 리포지터리와 서브모듈을 클론하기 전에 러너에서 실행할 명령 목록을 지정합니다. 예를 들어 다음 용도로 사용할 수 있습니다:

Git 구성 조정.
추적 변수 내보내기.

지원되는 값: 다음을 포함하는 배열:

단일 줄 명령.
여러 줄로 분할된 긴 명령.
YAML 앵커.

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'

관련 항목:

GitLab Runner 구성

`identity`#

히스토리

GitLab 16.9에서 google_cloud_support_feature_flag라는 플래그와 함께 도입되었습니다. 이 기능은 베타 상태입니다.
GitLab 17.1에서 GitLab.com에서 활성화되었습니다. 기능 플래그 google_cloud_support_feature_flag가 제거되었습니다.

이 기능은 베타 상태입니다.

identity를 사용하여 ID 페더레이션을 통해 타사 서비스에 인증합니다.

키워드 유형: 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를 사용하여 타사 서비스에 인증하기 위한 ID 토큰을 생성합니다. 이 방법으로 생성된 모든 JWT는 OIDC 인증을 지원합니다. 필수 하위 키워드 aud는 JWT의 aud 클레임을 구성하는 데 사용됩니다.

job 구성과 기본 구성은 함께 병합되지 않습니다. 파이프라인에 default:id_tokens가 정의되어 있고 job에도 id_tokens가 있는 경우 job 구성이 우선하며 기본 구성은 사용되지 않습니다.

지원되는 값:

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를 사용하여 job이 실행되는 Docker 이미지를 지정합니다.

job 구성과 기본 구성은 함께 병합되지 않습니다. 파이프라인에 default:image가 정의되어 있고 job에도 image가 있는 경우 job 구성이 우선하며 기본 구성은 사용되지 않습니다.

키워드 유형: 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 이미지는 파이프라인의 모든 job에 대한 기본값입니다. rspec 2.7 job은 job별 image 섹션으로 기본값을 재정의하므로 기본값을 사용하지 않습니다.

추가 세부 정보:

default 섹션이 아닌 최상위 수준에서 image를 사용하는 것은 더 이상 사용되지 않습니다.

관련 항목:

Docker 컨테이너에서 CI/CD job 실행.

`image:name`#

job이 실행되는 Docker 이미지 이름. 단독으로 사용되는 image와 유사합니다.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값: 필요한 경우 레지스트리 경로를 포함한 이미지 이름, 다음 형식 중 하나로:

<image-name> (latest 태그와 함께 <image-name> 사용과 동일)
<image-name>:<tag>
<image-name>@<digest>

CI/CD 변수는 지원됩니다.

image:name 예시:

test-job:
  image:
    name: "registry.example.com/my/image:latest"
  script: echo "Hello world"

관련 항목:

Docker 컨테이너에서 CI/CD job 실행.

`image:entrypoint`#

컨테이너의 엔트리포인트로 실행할 명령 또는 스크립트.

Docker 컨테이너가 생성될 때 entrypoint는 Docker --entrypoint 옵션으로 변환됩니다. 구문은 각 쉘 토큰이 배열의 별도 문자열인 Dockerfile ENTRYPOINT 지시어와 유사합니다.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

문자열.

image:entrypoint 예시:

test-job:
  image:
    name: super/sql:experimental
    entrypoint: [""]
  script: echo "Hello world"

관련 항목:

이미지의 엔트리포인트 재정의.

`image:docker`#

히스토리

GitLab 16.7에서 도입되었습니다. GitLab Runner 16.7 이상이 필요합니다.
user 입력 옵션이 GitLab 16.8에서 도입되었습니다.

image:docker를 사용하여 Docker executor 또는 Kubernetes executor를 사용하는 러너에 옵션을 전달합니다. 이 키워드는 다른 executor 유형에서는 작동하지 않습니다.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

Docker executor에 대한 옵션의 해시, 다음을 포함할 수 있습니다:

platform: 가져올 이미지의 아키텍처를 선택합니다. 지정하지 않으면 기본값은 호스트 러너와 동일한 플랫폼입니다.
user: 컨테이너를 실행할 때 사용할 사용자 이름 또는 UID를 지정합니다.

image:docker 예시:

arm-sql-job:
  script: echo "Run sql tests"
  image:
    name: super/sql:experimental
    docker:
      platform: arm64/v8
      user: dave

추가 세부 정보:

image:docker:platform은 docker pull --platform 옵션에 매핑됩니다.
image:docker:user는 docker run --user 옵션에 매핑됩니다.

`image:kubernetes`#

히스토리

GitLab 18.0에서 도입되었습니다. GitLab Runner 17.11 이상이 필요합니다.
user 입력 옵션이 GitLab Runner 17.11에서 도입되었습니다.
user 입력 옵션이 GitLab 18.0에서 uid:gid 형식을 지원하도록 확장되었습니다.

image:kubernetes를 사용하여 GitLab Runner Kubernetes executor에 옵션을 전달합니다. 이 키워드는 다른 executor 유형에서는 작동하지 않습니다.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

Kubernetes executor에 대한 옵션의 해시, 다음을 포함할 수 있습니다:

user: 컨테이너가 실행될 때 사용할 사용자 이름 또는 UID를 지정합니다. UID:GID 형식을 사용하여 GID를 설정할 수도 있습니다.

UID만 사용하는 image:kubernetes 예시:

arm-sql-job:
  script: echo "Run sql tests"
  image:
    name: super/sql:experimental
    kubernetes:
      user: "1001"

UID와 GID 모두 사용하는 image:kubernetes 예시:

arm-sql-job:
  script: echo "Run sql tests"
  image:
    name: super/sql:experimental
    kubernetes:
      user: "1001:1001"

`image:pull_policy`#

히스토리

GitLab 15.1에서 ci_docker_image_pull_policy라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
GitLab 15.2에서 GitLab.com 및 GitLab Self-Managed에서 활성화되었습니다.
GitLab 15.4에서 일반 공개되었습니다. 기능 플래그 ci_docker_image_pull_policy가 제거되었습니다.
GitLab Runner 15.1 이상이 필요합니다.

러너가 Docker 이미지를 가져오는 데 사용하는 풀 정책.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

단일 풀 정책 또는 배열의 여러 풀 정책. always, if-not-present, 또는 never일 수 있습니다.

image:pull_policy 예시:

job1:
  script: echo "A single pull policy."
  image:
    name: ruby:3.0
    pull_policy: if-not-present

job2:
  script: echo "Multiple pull policies."
  image:
    name: ruby:3.0
    pull_policy: [always, if-not-present]

추가 세부 정보:

러너가 정의된 풀 정책을 지원하지 않으면 job이 다음과 유사한 오류와 함께 실패합니다: ERROR: Job failed (system failure): the configured PullPolicies ([always]) are not allowed by AllowedPullPolicies ([never]).

관련 항목:

`inputs`#

히스토리

GitLab 18.10에서 도입되었습니다.

inputs를 사용하여 job에 대한 타입 지정 및 검증된 입력값을 정의합니다. Job 입력값은 job을 수동으로 실행하거나 재시도할 때 재정의할 수 있습니다.

Job 입력값은 타입 안전성과 유효성 검사를 제공하는 파라미터입니다. CI/CD 변수와 달리 job을 실행하거나 재시도할 때는 job에 명시적으로 정의된 입력값만 지정할 수 있습니다. 모든 job 입력값 이름은 사전에 정의되어야 합니다.

${{ job.inputs.INPUT_NAME }} Moa 표현식 구문으로 job 입력값을 참조합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

입력값 이름의 해시, 각 입력값은 하나 이상의 하위 키로 구성됩니다:

default (필수)
type
options
description
regex

inputs 예시:

test_job:
  inputs:
    test_suite:
      default: unit
      description: Which test suite to run
      options: [unit, integration, e2e]
    parallel_count:
      type: number
      default: 5
      description: Number of parallel test runners
    verbose:
      type: boolean
      default: false
      description: Enable verbose test output
  script:
    - 'echo "Running ${{ job.inputs.test_suite }} tests"'
    - 'if [ "${{ job.inputs.verbose }}" == "true" ]; then export TEST_VERBOSE=1; fi'
    - ./run_tests.sh --suite ${{ job.inputs.test_suite }} --parallel ${{ job.inputs.parallel_count }}

추가 세부 정보:

Job 입력값은 job이 생성될 때와 새 입력값으로 job을 재시도하려고 할 때 검증됩니다. 유효성 검사가 실패하면 job이 시작되지 않습니다.
Job 입력값은 정의된 job에만 적용되며 다른 job에서는 접근할 수 없습니다.
job 입력값을 지원하는 키워드의 전체 목록은 job 입력값을 사용할 수 있는 곳을 참조하세요.

`inputs:default`#

모든 job 입력값은 default로 정의된 기본값이 있어야 합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값: 입력값의 type과 일치하는 모든 값.

inputs:default 예시:

test_job:
  inputs:
    environment:
      default: staging
    timeout:
      type: number
      default: 30

`inputs:type`#

type을 사용하여 입력값의 데이터 타입을 정의합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

string (기본값)
number
boolean
array.

inputs:type 예시:

test_job:
  inputs:
    count:
      type: number
      default: 5
    enabled:
      type: boolean
      default: true

`inputs:description`#

description을 사용하여 입력값의 목적에 대한 정보를 제공합니다. 설명은 입력값의 동작에 영향을 주지 않습니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값: 문자열.

inputs:description 예시:

deploy_job:
  inputs:
    environment:
      default: staging
      description: Target deployment environment

`inputs:options`#

options를 사용하여 입력값에 허용되는 값 목록을 지정합니다.

입력값은 나열된 옵션 중 하나와 정확히 일치해야 합니다(대소문자 구분). 값이 옵션과 일치하지 않으면 유효성 검사가 실패합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값: 허용되는 값의 배열.

inputs:options 예시:

deploy_job:
  inputs:
    environment:
      default: staging
      options: [development, staging, production]

`inputs:regex`#

regex를 사용하여 입력값이 일치해야 하는 정규 표현식 패턴을 지정합니다.

값이 정규 표현식과 일치하지 않으면 유효성 검사가 실패합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값: 정규 표현식 문자열.

inputs:regex 예시:

deploy_job:
  inputs:
    version:
      default: v1.0.0
      regex: ^v\d+\.\d+\.\d+$

이 예시에서 v1.1.1의 입력값은 정규 표현식 유효성 검사를 통과하지만 v1.1.1-beta는 통과하지 못합니다.

`inherit`#

inherit를 사용하여 기본 키워드와 변수의 상속을 제어합니다.

`inherit:default`#

inherit:default를 사용하여 기본 키워드의 상속을 제어합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

true (기본값) 또는 false로 모든 기본 키워드의 상속을 활성화하거나 비활성화합니다.
상속할 특정 기본 키워드 목록.

inherit:default 예시:

default:
  retry: 2
  image: ruby:3.0
  interruptible: true

job1:
  script: echo "This job does not inherit any default keywords."
  inherit:
    default: false

job2:
  script: echo "This job inherits only the two listed default keywords. It does not inherit 'interruptible'."
  inherit:
    default:
      - retry
      - image

추가 세부 정보:

상속할 기본 키워드를 한 줄에 나열할 수도 있습니다: default: [keyword1, keyword2]

`inherit:variables`#

inherit:variables를 사용하여 기본 변수 키워드의 상속을 제어합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

true (기본값) 또는 false로 모든 기본 변수의 상속을 활성화하거나 비활성화합니다.
상속할 특정 변수 목록.

inherit:variables 예시:

variables:
  VARIABLE1: "This is default variable 1"
  VARIABLE2: "This is default variable 2"
  VARIABLE3: "This is default variable 3"

job1:
  script: echo "This job does not inherit any default variables."
  inherit:
    variables: false

job2:
  script: echo "This job inherits only the two listed default variables. It does not inherit 'VARIABLE3'."
  inherit:
    variables:
      - VARIABLE1
      - VARIABLE2

추가 세부 정보:

상속할 기본 변수를 한 줄에 나열할 수도 있습니다: variables: [VARIABLE1, VARIABLE2]

`interruptible`#

히스토리

trigger job에 대한 지원이 GitLab 16.8에서 도입되었습니다.

interruptible을 사용하여 동일한 ref에서 최신 커밋에 대한 새 파이프라인이 시작되는 경우 job이 완료되기 전에 취소하는 중복 파이프라인 자동 취소 기능을 구성합니다. 기능이 비활성화된 경우 키워드는 효과가 없습니다. 새 파이프라인은 새로운 변경 사항이 있는 커밋에 대한 것이어야 합니다. 예를 들어, UI에서 새 파이프라인을 선택하여 동일한 커밋에 대해 파이프라인을 실행하면 중복 파이프라인 자동 취소 기능은 효과가 없습니다.

중복 파이프라인 자동 취소 기능의 동작은 workflow:auto_cancel:on_new_commit 설정으로 제어할 수 있습니다.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

true 또는 false (기본값).

기본 동작의 interruptible 예시:

workflow:
  auto_cancel:
    on_new_commit: conservative # the default behavior

stages:
  - stage1
  - stage2
  - stage3

step-1:
  stage: stage1
  script:
    - echo "Can be canceled."
  interruptible: true

step-2:
  stage: stage2
  script:
    - echo "Can not be canceled."

step-3:
  stage: stage3
  script:
    - echo "Because step-2 can not be canceled, this step can never be canceled, even though it's set as interruptible."
  interruptible: true

이 예시에서 새 파이프라인은 실행 중인 파이프라인을 다음과 같이 처리합니다:

step-1만 실행 중이거나 대기 중인 경우 취소합니다.
step-2가 시작된 후에는 취소하지 않습니다.

auto_cancel:on_new_commit:interruptible 설정의 interruptible 예시:

workflow:
  auto_cancel:
    on_new_commit: interruptible

stages:
  - stage1
  - stage2
  - stage3

step-1:
  stage: stage1
  script:
    - echo "Can be canceled."
  interruptible: true

step-2:
  stage: stage2
  script:
    - echo "Can not be canceled."

step-3:
  stage: stage3
  script:
    - echo "Can be canceled."
  interruptible: true

이 예시에서 새 파이프라인은 step-1과 step-3이 실행 중이거나 대기 중인 경우 취소합니다.

추가 세부 정보:

빌드 job처럼 시작된 후에도 안전하게 취소할 수 있는 job에만 interruptible: true를 설정합니다. 배포 job은 부분 배포를 방지하기 위해 일반적으로 취소하면 안 됩니다.
기본 동작 또는 workflow:auto_cancel:on_new_commit: conservative를 사용하는 경우:
- 아직 시작되지 않은 job은 job 구성에 관계없이 항상 interruptible: true로 간주됩니다. interruptible 구성은 job이 시작된 후에만 고려됩니다.
- 실행 중인 파이프라인은 모든 실행 중인 job이 interruptible: true로 구성되어 있거나 어느 시점에도 interruptible: false로 구성된 job이 시작되지 않은 경우에만 취소됩니다. interruptible: false인 job이 시작되면 전체 파이프라인은 더 이상 중단 가능한 것으로 간주되지 않습니다.
- 파이프라인이 다운스트림 파이프라인을 트리거했지만 다운스트림 파이프라인에서 interruptible: false인 job이 아직 시작되지 않은 경우 다운스트림 파이프라인도 취소됩니다.
interruptible: false인 선택적 수동 job을 파이프라인의 첫 번째 stage에 추가하여 사용자가 파이프라인이 자동으로 취소되지 않도록 수동으로 방지할 수 있습니다. 사용자가 job을 시작하면 파이프라인은 중복 파이프라인 자동 취소 기능으로 취소할 수 없습니다.
trigger job과 함께 interruptible을 사용하는 경우:
- 트리거된 다운스트림 파이프라인은 trigger job의 interruptible 구성에 의해 절대 영향을 받지 않습니다.
- workflow:auto_cancel이 conservative로 설정된 경우 trigger job의 interruptible 구성은 효과가 없습니다.
- workflow:auto_cancel이 interruptible로 설정된 경우 interruptible: true인 trigger job은 자동으로 취소될 수 있습니다.

`needs`#

needs를 사용하여 순서 없이 job을 실행합니다. needs를 사용하는 job 간의 관계는 방향성 비순환 그래프로 시각화할 수 있습니다.

stage 순서를 무시하고 다른 job이 완료될 때까지 기다리지 않고 일부 job을 실행할 수 있습니다. 여러 stage의 job이 동시에 실행될 수 있습니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

job의 배열 (최대 50개 job).
빈 배열 ([]), job을 파이프라인이 생성되는 즉시 시작하도록 설정합니다.

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

이 예시는 네 가지 실행 경로를 생성합니다:

Linter: lint job은 needs: []로 인해 build stage가 완료될 때까지 기다리지 않고 즉시 실행됩니다.
Linux 경로: linux:rspec job은 linux:build job이 완료되는 즉시 실행되며 mac:build가 완료될 때까지 기다리지 않습니다.
macOS 경로: mac:rspec job은 mac:build job이 완료되는 즉시 실행되며 linux:build가 완료될 때까지 기다리지 않습니다.
production job은 이전의 모든 job이 완료되면 실행됩니다: lint, linux:build, linux:rspec, mac:build, mac:rspec.

추가 세부 정보:

단일 job이 needs 배열에 가질 수 있는 최대 job 수는 제한됩니다:
- GitLab.com의 경우 제한은 50입니다. 자세한 내용은 이슈 350398을 참조하세요.
- GitLab Self-Managed 및 GitLab Dedicated의 경우 기본 제한은 50입니다. 관리자 영역에서 CI/CD 제한을 업데이트하여 이 제한을 변경할 수 있습니다.
needs가 parallel 키워드를 사용하는 job을 참조하는 경우 하나의 job만이 아닌 병렬로 생성된 모든 job에 의존합니다. 또한 기본적으로 모든 병렬 job에서 아티팩트를 다운로드합니다. 아티팩트의 이름이 동일한 경우 서로 덮어쓰고 마지막으로 다운로드된 것만 저장됩니다.
- needs가 병렬화된 job의 하위 집합(전체가 아닌)을 참조하도록 하려면 needs:parallel:matrix 키워드를 사용하세요.
구성 중인 job과 동일한 stage의 job을 참조할 수 있습니다.
needs가 only, except, 또는 rules로 인해 파이프라인에 추가되지 않을 수 있는 job을 참조하는 경우 파이프라인 생성이 실패할 수 있습니다. needs:optional 키워드를 사용하여 파이프라인 생성 실패를 해결하세요.
파이프라인에 needs: []인 job과 .pre stage의 job이 있는 경우 파이프라인이 생성되는 즉시 모두 시작됩니다. needs: []인 job은 즉시 시작되고 .pre stage의 job도 즉시 시작됩니다.

`needs:artifacts`#

job이 needs를 사용할 때 더 이상 이전 stage의 모든 아티팩트를 기본으로 다운로드하지 않습니다. needs가 있는 job은 이전 stage가 완료되기 전에 시작할 수 있기 때문입니다. needs를 사용하면 needs 구성에 나열된 job의 아티팩트만 다운로드할 수 있습니다.

artifacts: true (기본값) 또는 artifacts: false를 사용하여 needs를 사용하는 job에서 아티팩트를 다운로드할 때를 제어합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다. 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 job은 build_job1 아티팩트를 다운로드합니다.
test-job2 job은 build_job2 아티팩트를 다운로드하지 않습니다.
test-job3 job은 세 가지 build_jobs의 아티팩트를 모두 다운로드합니다. 세 필요한 job 모두에서 artifacts가 true이거나 기본적으로 true이기 때문입니다.

추가 세부 정보:

동일한 job에서 needs와 dependencies를 함께 사용하지 않는 것이 좋습니다.

`needs:project`#

needs:project를 사용하여 다른 파이프라인의 최대 5개 job에서 아티팩트를 다운로드합니다. 아티팩트는 지정된 ref에 대한 지정된 job의 최신 성공적인 실행에서 다운로드됩니다. 여러 job을 지정하려면 needs 키워드 아래에 각각을 별도의 배열 항목으로 추가합니다.

ref에 대해 파이프라인이 실행 중인 경우 needs:project가 있는 job은 파이프라인이 완료될 때까지 기다리지 않습니다. 대신 지정된 job의 최신 성공적인 실행에서 아티팩트가 다운로드됩니다.

needs:project는 job, ref, artifacts와 함께 사용해야 합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

needs:project: 네임스페이스와 그룹을 포함한 전체 프로젝트 경로.
job: 아티팩트를 다운로드할 job.
ref: 아티팩트를 다운로드할 ref.
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 job의 아티팩트를 다운로드합니다.

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

추가 세부 정보:

현재 프로젝트의 다른 파이프라인에서 아티팩트를 다운로드하려면 project를 현재 프로젝트와 동일하게 설정하되 현재 파이프라인과 다른 ref를 사용합니다. 동일한 ref에서 실행되는 동시 파이프라인이 아티팩트를 덮어쓸 수 있습니다.
파이프라인을 실행하는 사용자는 그룹 또는 프로젝트에 대한 Reporter, Developer, Maintainer, 또는 Owner 역할이 있어야 하거나 그룹/프로젝트가 공개 가시성이어야 합니다.
동일한 job에서 needs:project와 trigger를 사용할 수 없습니다.
다른 파이프라인에서 아티팩트를 다운로드하기 위해 needs:project를 사용하는 경우 job은 필요한 job이 완료될 때까지 기다리지 않습니다. needs를 사용하여 job이 완료될 때까지 기다리기는 동일한 파이프라인의 job으로 제한됩니다. 다른 파이프라인의 필요한 job이 아티팩트를 다운로드하려는 job보다 먼저 완료되는지 확인하세요.
parallel에서 실행되는 job에서 아티팩트를 다운로드할 수 없습니다.
project, job, ref에서 CI/CD 변수를 지원합니다.

관련 항목:

부모-자식 파이프라인 간에 아티팩트를 다운로드하려면 needs:pipeline:job을 사용하세요.

`needs:pipeline:job`#

자식 파이프라인은 부모 파이프라인 또는 동일한 부모-자식 파이프라인 계층의 다른 자식 파이프라인에서 성공적으로 완료된 job의 아티팩트를 다운로드할 수 있습니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

needs:pipeline: 파이프라인 ID. 동일한 부모-자식 파이프라인 계층에 있는 파이프라인이어야 합니다.
job: 아티팩트를 다운로드할 job.

needs:pipeline:job 예시:

부모 파이프라인 (.gitlab-ci.yml):

stages:
  - build
  - test

create-artifact:
  stage: build
  script: echo "sample artifact" > artifact.txt
  artifacts:
    paths: [artifact.txt]

child-pipeline:
  stage: test
  trigger:
    include: child.yml
    strategy: mirror
  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 job은 일부 아티팩트를 생성합니다. child-pipeline job은 자식 파이프라인을 트리거하고 CI_PIPELINE_ID 변수를 새 PARENT_PIPELINE_ID 변수로 자식 파이프라인에 전달합니다. 자식 파이프라인은 needs:pipeline에서 해당 변수를 사용하여 부모 파이프라인에서 아티팩트를 다운로드할 수 있습니다. create-artifact와 child-pipeline job을 후속 stage에 배치하면 use-artifact job은 create-artifact가 성공적으로 완료된 경우에만 실행됩니다.

추가 세부 정보:

pipeline 속성은 현재 파이프라인 ID ($CI_PIPELINE_ID)를 허용하지 않습니다. 현재 파이프라인의 job에서 아티팩트를 다운로드하려면 needs:artifacts를 사용하세요.
trigger job에서 needs:pipeline:job을 사용하거나 멀티 프로젝트 파이프라인에서 아티팩트를 가져오는 데 사용할 수 없습니다. 멀티 프로젝트 파이프라인에서 아티팩트를 가져오려면 needs:project를 사용하세요.
needs:pipeline:job에 나열된 job은 success 상태로 완료되어야 아티팩트를 가져올 수 있습니다. 이슈 367229에서 아티팩트가 있는 모든 job에서 아티팩트를 가져올 수 있도록 허용할 것을 제안하고 있습니다.

`needs:optional`#

파이프라인에 때때로 존재하지 않는 job을 필요로 하려면 needs 구성에 optional: true를 추가합니다. 정의하지 않으면 optional: false가 기본값입니다.

rules, only 또는 except를 사용하고 include와 함께 추가된 job은 항상 파이프라인에 추가되지 않을 수 있습니다. GitLab은 파이프라인을 시작하기 전에 needs 관계를 확인합니다:

needs 항목에 optional: true가 있고 필요한 job이 파이프라인에 있는 경우 job은 시작하기 전에 완료될 때까지 기다립니다.
필요한 job이 없는 경우 다른 모든 needs 요구 사항이 충족되면 job을 시작할 수 있습니다.
needs 섹션에 선택적 job만 있고 어느 것도 파이프라인에 추가되지 않은 경우 job은 즉시 시작됩니다 (빈 needs 항목: needs: []와 동일).
필요한 job에 optional: false가 있지만 파이프라인에 추가되지 않은 경우 파이프라인은 다음과 유사한 오류와 함께 시작에 실패합니다: 'job1' job needs 'job2' job, but it was not added to the pipeline.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

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는 stage 순서대로 시작됩니다.
브랜치가 기본 브랜치인 경우 test-job2가 파이프라인에 추가되므로:
- deploy-job은 test-job1과 test-job2가 모두 완료될 때까지 기다립니다.
- review-job은 test-job2가 완료될 때까지 기다립니다.
브랜치가 기본 브랜치가 아닌 경우 test-job2가 파이프라인에 추가되지 않으므로:
- deploy-job은 test-job1만 완료될 때까지 기다리고 누락된 test-job2를 기다리지 않습니다.
- review-job은 다른 필요한 job이 없어서 즉시 시작됩니다 (build-job과 동시에), needs: []와 같습니다.

추가 세부 정보:

needs:parallel:matrix와 함께 needs:optional을 사용할 수 없습니다.

`needs:pipeline`#

needs:pipeline 키워드를 사용하여 업스트림 파이프라인에서 job으로 파이프라인 상태를 미러링할 수 있습니다. 기본 브랜치의 최신 파이프라인 상태가 job에 복제됩니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

네임스페이스와 그룹을 포함한 전체 프로젝트 경로. 프로젝트가 동일한 그룹 또는 네임스페이스에 있는 경우 project 키워드에서 생략할 수 있습니다. 예: project: group/project-name 또는 project: project-name.

needs:pipeline 예시:

upstream_status:
  stage: test
  needs:
    pipeline: other/project

추가 세부 정보:

needs:pipeline에 job 키워드를 추가하면 job은 더 이상 파이프라인 상태를 미러링하지 않습니다. 동작이 needs:pipeline:job으로 변경됩니다.

`needs:parallel:matrix`#

히스토리

GitLab 16.3에서 도입되었습니다.

Job은 parallel:matrix를 사용하여 단일 파이프라인에서 여러 번 병렬로 실행할 수 있지만 job의 각 인스턴스마다 다른 변수 값을 사용합니다.

needs:parallel:matrix를 사용하여 병렬화된 job에 따라 순서 없이 job을 실행합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다. needs:job과 함께 사용해야 합니다.

지원되는 값: 매트릭스 식별자의 해시 배열:

식별자와 값은 parallel:matrix job에 정의된 식별자와 값에서 선택해야 합니다.
매트릭스 표현식을 사용할 수 있습니다.

needs:parallel:matrix 예시:

linux:build:
  stage: build
  script: echo "Building 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 "Running rspec on linux..."

이전 예시는 다음 job을 생성합니다:

linux:build: [aws, monitoring]
linux:build: [aws, app1]
linux:build: [aws, app2]
linux:rspec

linux:rspec job은 linux:build: [aws, app1] job이 완료되는 즉시 실행됩니다.

추가 세부 정보:

needs:optional과 함께 needs:parallel:matrix를 사용할 수 없습니다.

needs:parallel:matrix의 매트릭스 식별자 순서는 필요한 job의 매트릭스 변수 순서와 일치해야 합니다. 예를 들어 이전 예시에서 linux:rspec job의 변수 순서를 반전하면 유효하지 않습니다:

linux:rspec:
  stage: test
  needs:
    - job: linux:build
      parallel:
        matrix:
          - STACK: app1        # The variable order does not match `linux:build` and is invalid.
            PROVIDER: aws
  script: echo "Running rspec on linux..."

관련 항목:

`pages`#

pages를 사용하여 GitLab에 정적 콘텐츠를 업로드하는 GitLab Pages job을 정의합니다. 그러면 콘텐츠가 웹사이트로 게시됩니다.

다음을 수행해야 합니다:

pages: true를 정의하여 public이라는 디렉토리를 게시하거나
다른 콘텐츠 디렉토리를 사용하려면 pages.publish를 정의합니다.
콘텐츠 디렉토리의 루트에 비어 있지 않은 index.html 파일이 있어야 합니다.

키워드 유형: Job 키워드 또는 Job 이름(더 이상 사용되지 않음). job의 일부로만 사용할 수 있습니다.

지원되는 값:

불리언. true로 설정하면 기본 구성을 사용합니다.
구성 옵션의 해시, 자세한 내용은 다음 섹션을 참조하세요.

pages 예시:

create-pages:
  stage: deploy
  script:
    - mv my-html-content public
  pages: true  # specifies that this is a Pages job and publishes the default public directory
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  environment: production

이 예시는 my-html-content/ 디렉토리의 이름을 public/으로 변경합니다. 이 디렉토리는 아티팩트로 내보내지고 GitLab Pages로 게시됩니다.

구성 해시를 사용하는 예시:

create-pages:
  stage: deploy
  script:
    - echo "nothing to do here"
  pages:  # specifies that this is a Pages job and publishes the default public directory
    publish: my-html-content
    expire_in: "1 week"
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  environment: production

이 예시는 디렉토리를 이동하지 않고 publish 속성을 직접 사용합니다. 또한 일주일 후에 pages 배포가 게시 취소되도록 구성합니다.

추가 세부 정보:

pages를 job 이름으로 사용하는 것은 더 이상 사용되지 않습니다.
Pages 배포를 트리거하지 않고 pages를 job 이름으로 사용하려면 pages 속성을 false로 설정하세요.

`pages.publish`#

히스토리

GitLab 16.1에서 도입되었습니다.
GitLab 17.9에서 publish 속성에 변수를 전달할 때 허용하도록 변경되었습니다.
GitLab 17.9에서 publish 속성이 pages 키워드 아래로 이동되었습니다.
GitLab 17.10에서 pages.publish 경로가 artifacts:paths에 자동으로 추가되었습니다.

pages.publish를 사용하여 pages job의 콘텐츠 디렉토리를 구성합니다.

키워드 유형: Job 키워드. pages job의 일부로만 사용할 수 있습니다.

지원되는 값: Pages 콘텐츠가 포함된 디렉토리 경로. GitLab 17.10 이상에서는 지정하지 않으면 기본 public 디렉토리가 사용되고 지정하면 이 경로가 artifacts:paths에 자동으로 추가됩니다.

pages.publish 예시:

create-pages:
  stage: deploy
  script:
    - npx @11ty/eleventy --input=path/to/eleventy/root --output=dist
  pages:
    publish: dist  # this path is automatically appended to artifacts:paths
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  environment: production

이 예시는 Eleventy를 사용하여 정적 웹사이트를 생성하고 생성된 HTML 파일을 dist/ 디렉토리에 출력합니다. 이 디렉토리는 아티팩트로 내보내지고 GitLab Pages로 게시됩니다.

pages.publish 필드에 변수를 사용할 수도 있습니다. 예시:

create-pages:
  stage: deploy
  script:
    - mkdir -p $CUSTOM_FOLDER/$CUSTOM_PATH
    - cp -r public $CUSTOM_FOLDER/$CUSTOM_SUBFOLDER
  pages:
    publish: $CUSTOM_FOLDER/$CUSTOM_SUBFOLDER  # this path is automatically appended to artifacts:paths
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  variables:
    CUSTOM_FOLDER: "custom_folder"
    CUSTOM_SUBFOLDER: "custom_subfolder"

지정된 publish 경로는 빌드 루트에 상대적이어야 합니다.

추가 세부 정보:

최상위 수준 publish 키워드는 더 이상 사용되지 않으며 이제 pages 키워드 아래에 중첩되어야 합니다.

`pages.path_prefix`#

히스토리

GitLab 16.7에서 pages_multiple_versions_setting이라는 플래그와 함께 실험으로 도입되었으며 기본적으로 비활성화되어 있습니다.
GitLab 17.4에서 GitLab.com, GitLab Self-Managed, GitLab Dedicated에서 활성화되었습니다.
GitLab 17.8에서 마침표를 허용하도록 변경되었습니다.
GitLab 17.9에서 일반 공개되었습니다. 기능 플래그 pages_multiple_versions_setting이 제거되었습니다.

pages.path_prefix를 사용하여 GitLab Pages의 병렬 배포에 대한 경로 접두사를 구성합니다.

키워드 유형: Job 키워드. pages job의 일부로만 사용할 수 있습니다.

지원되는 값:

문자열
CI/CD 변수
둘의 조합

주어진 값은 소문자로 변환되고 63바이트로 단축됩니다. 영숫자 또는 마침표를 제외한 모든 것은 하이픈으로 대체됩니다. 선행 및 후행 하이픈이나 마침표는 허용되지 않습니다.

pages.path_prefix 예시:

create-pages:
  stage: deploy
  script:
    - echo "Pages accessible through ${CI_PAGES_URL}"
  pages:  # specifies that this is a Pages job and publishes the default public directory
    path_prefix: "$CI_COMMIT_BRANCH"

이 예시에서 각 브랜치에 대해 다른 pages 배포가 생성됩니다.

`pages.expire_in`#

히스토리

GitLab 17.4에서 도입되었습니다.
변수 지원이 GitLab 17.11에서 도입되었습니다.

expire_in을 사용하여 배포가 만료되기 전에 얼마나 사용 가능해야 하는지 지정합니다. 배포가 만료되면 10분마다 실행되는 cron job에 의해 비활성화됩니다.

기본적으로 병렬 배포는 24시간 후에 자동으로 만료됩니다. 이 동작을 비활성화하려면 값을 never로 설정합니다.

키워드 유형: Job 키워드. pages job의 일부로만 사용할 수 있습니다.

지원되는 값: 만료 시간. 단위가 제공되지 않으면 시간은 초 단위입니다. 변수도 지원됩니다. 유효한 값은 다음을 포함합니다:

'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
$DURATION

pages.expire_in 예시:

create-pages:
  stage: deploy
  script:
    - echo "Pages accessible through ${CI_PAGES_URL}"
  pages:  # specifies that this is a Pages job and publishes the default public directory
    expire_in: 1 week

`parallel`#

히스토리

GitLab 15.9에서 parallel의 최대값이 50에서 200으로 증가했습니다 (도입).

parallel을 사용하여 단일 파이프라인에서 여러 번 병렬로 job을 실행합니다.

여러 러너가 있거나 단일 러너가 여러 job을 동시에 실행하도록 구성되어 있어야 합니다.

병렬 job은 job_name 1/N에서 job_name N/N까지 순차적으로 이름이 지정됩니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

1에서 200까지의 숫자 값.

parallel 예시:

test:
  script: rspec
  parallel: 5

이 예시는 test 1/5에서 test 5/5까지 이름이 지정된 5개의 job을 병렬로 생성합니다.

추가 세부 정보:

모든 병렬 job에는 CI_NODE_INDEX와 CI_NODE_TOTAL 사전 정의된 CI/CD 변수가 설정됩니다.
parallel을 사용하는 job이 있는 파이프라인은 다음과 같을 수 있습니다:
- 사용 가능한 러너보다 더 많은 job이 병렬로 생성될 수 있습니다. 초과 job은 대기열에 넣어지고 사용 가능한 러너를 기다리는 동안 pending으로 표시됩니다.
- 파이프라인을 생성하면 모든 활성 파이프라인의 총 job 수가 인스턴스 제한을 초과하게 되는 경우 job_activity_limit_exceeded 오류와 함께 실패할 수 있습니다.

관련 항목:

대규모 job 병렬화.

`parallel:matrix`#

히스토리

GitLab 15.9에서 최대 순열 수가 50에서 200으로 증가했습니다 (도입).

parallel:matrix를 사용하여 단일 파이프라인에서 여러 번 병렬로 job을 실행하되 job의 각 인스턴스마다 다른 변수 값을 사용합니다.

여러 러너가 있거나 단일 러너가 여러 job을 동시에 실행하도록 구성되어 있어야 합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값: 변수의 해시 배열:

변수 이름이 되는 매트릭스 식별자는 숫자, 문자, 밑줄 (_)만 사용할 수 있습니다.
값은 문자열이거나 문자열 배열이어야 합니다.
순열의 수는 200을 초과할 수 없습니다.

parallel:matrix 예시:

deploystacks:
  stage: deploy
  script:
    - bin/deploy
  parallel:
    matrix:
      - PROVIDER: aws
        STACK:
          - monitoring
          - app1
          - app2
      - PROVIDER: [gcp, vultr]
        STACK: [data, processing]
  environment: $PROVIDER/$STACK

이 예시는 PROVIDER와 STACK에 대해 다른 값을 가진 7개의 병렬 deploystacks job을 생성합니다:

deploystacks: [aws, monitoring]
deploystacks: [aws, app1]
deploystacks: [aws, app2]
deploystacks: [gcp, data]
deploystacks: [gcp, processing]
deploystacks: [vultr, data]
deploystacks: [vultr, processing]

추가 세부 정보:

parallel:matrix job은 서로를 구별하기 위해 job 이름에 매트릭스 값을 추가하지만 큰 값으로 인해 이름이 제한을 초과할 수 있습니다:
- Job 이름은 255자 이하여야 합니다.
- needs를 사용할 때 job 이름은 128자 이하여야 합니다.
매트릭스 값을 rules:if의 변수로 사용할 수 없습니다.
동일한 값이지만 이름이 다른 여러 매트릭스 구성을 생성할 수 없습니다. Job 이름은 이름이 아닌 매트릭스 값에서 생성되므로 동일한 값을 가진 매트릭스 항목은 서로 덮어쓰는 동일한 job 이름을 생성합니다.

예를 들어, 이 test 구성은 동일한 job의 두 시리즈를 생성하려 하지만 OS2 버전이 OS 버전을 덮어씁니다:
```
test:
  parallel:
    matrix:
      - OS: [ubuntu]
        PROVIDER: [aws, gcp]
      - OS2: [ubuntu]
        PROVIDER: [aws, gcp]
```

관련 항목:

`release`#

release를 사용하여 릴리스를 생성합니다.

release job은 $PATH에 있는 glab CLI에 액세스할 수 있어야 합니다.

Docker executor를 사용하는 경우 GitLab 컨테이너 레지스트리에서 이 이미지를 사용할 수 있습니다: registry.gitlab.com/gitlab-org/cli:latest

Shell executor 또는 유사한 executor를 사용하는 경우 러너가 등록된 서버에 glab CLI를 설치합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값: release 하위 키:

tag_name
tag_message (선택 사항)
name (선택 사항)
description
ref (선택 사항)
milestones (선택 사항)
released_at (선택 사항)
assets:links (선택 사항)

release 키워드 예시:

release_job:
  stage: release
  image: registry.gitlab.com/gitlab-org/cli:latest
  rules:
    - if: $CI_COMMIT_TAG                  # Run this job when a tag is created manually
  script:
    - echo "Running the release job."
  release:
    tag_name: $CI_COMMIT_TAG
    name: 'Release $CI_COMMIT_TAG'
    description: 'Release created using the CLI.'

이 예시는 다음 경우에 릴리스를 생성합니다:

Git 태그를 푸시할 때.
UI의 코드 > 태그에서 Git 태그를 추가할 때.

추가 세부 정보:

trigger job을 제외한 모든 release job은 script 키워드를 포함해야 합니다. release job은 script 명령의 출력을 사용할 수 있습니다. script가 필요하지 않은 경우 자리 표시자를 사용할 수 있습니다:
```
script:
  - echo "release job"
```
이 요구 사항을 제거하기 위한 이슈가 있습니다.
release 섹션은 script 키워드 이후와 after_script 이전에 실행됩니다.
릴리스는 job의 메인 스크립트가 성공한 경우에만 생성됩니다.
릴리스가 이미 존재하는 경우 업데이트되지 않으며 release 키워드가 있는 job이 실패합니다.

관련 항목:

`release:tag_name`#

필수. 릴리스의 Git 태그.

프로젝트에 태그가 아직 존재하지 않으면 릴리스와 동시에 생성됩니다. 새 태그는 파이프라인과 연결된 SHA를 사용합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

태그 이름.

CI/CD 변수는 지원됩니다.

release:tag_name 예시:

프로젝트에 새 태그가 추가될 때 릴리스를 생성하려면:

$CI_COMMIT_TAG CI/CD 변수를 tag_name으로 사용합니다.
rules:if를 사용하여 새 태그에 대해서만 job을 실행하도록 구성합니다.

job:
  script: echo "Running the release job for the new tag."
  release:
    tag_name: $CI_COMMIT_TAG
    description: 'Release description'
  rules:
    - if: $CI_COMMIT_TAG

릴리스와 새 태그를 동시에 생성하려면 rules에서 새 태그에 대해서만 job을 실행하도록 구성하지 않아야 합니다. 시맨틱 버저닝 예시:

job:
  script: echo "Running the release job and creating a new tag."
  release:
    tag_name: ${MAJOR}_${MINOR}_${REVISION}
    description: 'Release description'
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"

`release:tag_message`#

태그가 존재하지 않으면 새로 생성된 태그에 tag_message로 지정된 메시지가 주석으로 추가됩니다. 생략하면 경량 태그가 생성됩니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

텍스트 문자열.

release:tag_message 예시:

  release_job:
    stage: release
    release:
      tag_name: $CI_COMMIT_TAG
      description: 'Release description'
      tag_message: 'Annotated tag message'

`release:name`#

릴리스 이름. 생략하면 release: tag_name 값으로 채워집니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

텍스트 문자열.

release:name 예시:

  release_job:
    stage: release
    release:
      name: 'Release $CI_COMMIT_TAG'

`release:description`#

릴리스의 긴 설명.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

긴 설명이 있는 문자열.
설명이 포함된 파일 경로.
- 파일 위치는 프로젝트 디렉토리 ($CI_PROJECT_DIR)에 상대적이어야 합니다.
- 파일이 심볼릭 링크인 경우 $CI_PROJECT_DIR에 있어야 합니다.
- ./path/to/file과 파일 이름에는 공백이 포함될 수 없습니다.

release:description 예시:

job:
  release:
    tag_name: ${MAJOR}_${MINOR}_${REVISION}
    description: './path/to/CHANGELOG.md'

추가 세부 정보:

description은 glab을 실행하는 쉘에 의해 평가됩니다. CI/CD 변수를 사용하여 설명을 정의할 수 있지만 일부 쉘은 다른 구문을 사용으로 변수를 참조합니다. 마찬가지로 일부 쉘은 특수 문자를 이스케이프해야 할 수 있습니다. 예를 들어 백틱 (`)은 백슬래시 (\)로 이스케이프해야 할 수 있습니다.

`release:ref`#

release: tag_name이 아직 존재하지 않는 경우 릴리스의 ref.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

커밋 SHA, 다른 태그 이름, 또는 브랜치 이름.

`release:milestones`#

릴리스와 연결된 각 마일스톤의 제목.

`release:released_at`#

릴리스가 준비된 날짜와 시간.

지원되는 값:

따옴표로 묶인 날짜, ISO 8601 형식으로 표현.

release:released_at 예시:

released_at: '2021-03-15T08:00:00Z'

추가 세부 정보:

정의하지 않으면 현재 날짜와 시간이 사용됩니다.

`release:assets:links`#

release:assets:links를 사용하여 릴리스에 자산 링크를 포함합니다.

release:assets:links 예시:

assets:
  links:
    - name: 'asset1'
      url: 'https://example.com/assets/1'
    - name: 'asset2'
      url: 'https://example.com/assets/2'
      filepath: '/pretty/url/1' # optional
      link_type: 'other' # optional

`resource_group`#

resource_group을 사용하여 동일한 프로젝트의 다른 파이프라인에서 job이 상호 배타적임을 보장하는 리소스 그룹을 생성합니다.

예를 들어 동일한 리소스 그룹에 속하는 여러 job이 동시에 대기열에 있는 경우 job 중 하나만 시작됩니다. 다른 job은 resource_group이 해제될 때까지 기다립니다.

리소스 그룹은 다른 프로그래밍 언어의 세마포어와 유사하게 동작합니다.

배포 기본 설정에 대한 job 동시성을 전략적으로 제어하기 위해 프로세스 모드를 선택할 수 있습니다. 기본 프로세스 모드는 unordered입니다. 리소스 그룹의 프로세스 모드를 변경하려면 API를 사용하여 기존 리소스 그룹을 편집하는 요청을 보냅니다.

환경당 여러 리소스 그룹을 정의할 수 있습니다. 예를 들어 물리적 디바이스에 배포할 때 여러 물리적 디바이스가 있을 수 있습니다. 각 디바이스에 배포할 수 있지만 언제든지 디바이스당 하나의 배포만 발생할 수 있습니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

문자, 숫자, -, _, /, $, {, }, ., 공백만 허용됩니다. /로 시작하거나 끝날 수 없습니다. CI/CD 변수는 지원됩니다.

resource_group 예시:

deploy-to-production:
  script: deploy
  resource_group: production

이 예시에서 두 개의 별도 파이프라인에서 두 개의 deploy-to-production job은 동시에 실행될 수 없습니다. 결과적으로 프로덕션 환경에 동시 배포가 절대 발생하지 않도록 보장할 수 있습니다.

관련 항목:

크로스 프로젝트/부모-자식 파이프라인을 통한 파이프라인 수준의 동시성 제어.

`retry`#

retry를 사용하여 job이 실패한 경우 재시도 횟수를 구성합니다. 정의하지 않으면 기본값은 0이며 job은 재시도하지 않습니다.

job이 실패하면 성공하거나 최대 재시도 횟수에 도달할 때까지 최대 두 번 더 처리됩니다.

기본적으로 모든 실패 유형으로 인해 job이 재시도됩니다. retry:when 또는 retry:exit_codes를 사용하여 재시도할 실패를 선택합니다.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

0 (기본값), 1, 또는 2.

retry 예시:

test:
  script: rspec
  retry: 2

test_advanced:
  script:
    - echo "Run a script that results in exit code 137."
    - exit 137
  retry:
    max: 2
    when: runner_system_failure
    exit_codes: 137

test_advanced는 종료 코드가 137이거나 러너 시스템 실패가 있는 경우 최대 2번 재시도됩니다.

`retry:when`#

retry:when을 retry:max와 함께 사용하여 특정 실패 사례에 대해서만 job을 재시도합니다. retry:max는 retry와 같이 최대 재시도 횟수이며 0, 1, 또는 2일 수 있습니다.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

단일 실패 유형 또는 하나 이상의 실패 유형 배열:
always: 모든 실패에 대해 재시도 (기본값).
unknown_failure: 실패 이유를 알 수 없을 때 재시도.
script_failure: 다음 경우에 재시도:
- 스크립트가 실패했을 때.
- 러너가 Docker 이미지를 가져오지 못했을 때. docker, docker+machine, kubernetes executor 의 경우.
api_failure: API 실패 시 재시도.
stuck_or_timeout_failure: job이 멈추거나 시간 초과될 때 재시도.
runner_system_failure: 러너 시스템 실패가 있는 경우 재시도 (예: job 설정 실패).
runner_unsupported: 러너가 지원되지 않는 경우 재시도.
stale_schedule: 지연된 job을 실행할 수 없는 경우 재시도.
job_execution_timeout: 스크립트가 job에 설정된 최대 실행 시간을 초과한 경우 재시도.
archived_failure: job이 아카이브되어 실행할 수 없는 경우 재시도.
unmet_prerequisites: job이 사전 조건 작업을 완료하지 못한 경우 재시도.
scheduler_failure: 스케줄러가 job을 러너에 할당하지 못한 경우 재시도.
data_integrity_failure: 알 수 없는 job 문제가 있는 경우 재시도.

retry:when 예시 (단일 실패 유형):

test:
  script: rspec
  retry:
    max: 2
    when: runner_system_failure

러너 시스템 실패 외의 다른 실패가 있는 경우 job은 재시도되지 않습니다.

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 16.11에서 GitLab.com 및 GitLab Self-Managed에서 활성화되었습니다.
GitLab 17.5에서 일반 공개되었습니다. 기능 플래그 ci_retry_on_exit_codes가 제거되었습니다.

retry:exit_codes를 retry:max와 함께 사용하여 특정 실패 사례에 대해서만 job을 재시도합니다. retry:max는 retry와 같이 최대 재시도 횟수이며 0, 1, 또는 2일 수 있습니다.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

단일 종료 코드.
종료 코드 배열.

retry:exit_codes 예시:

test_job_1:
  script:
    - echo "Run a script that results in exit code 1. This job isn't retried."
    - exit 1
  retry:
    max: 2
    exit_codes: 137

test_job_2:
  script:
    - echo "Run a script that results in exit code 137. This job will be retried."
    - exit 137
  retry:
    max: 1
    exit_codes:
      - 255
      - 137

관련 항목:

변수를 사용하여 job 실행의 특정 단계에 대한 재시도 횟수를 지정할 수 있습니다.

`rules`#

rules를 사용하여 파이프라인에서 job을 포함하거나 제외합니다.

rules는 파이프라인이 생성될 때 평가되며 순서대로 평가됩니다. 일치하는 것이 발견되면 더 이상 규칙이 확인되지 않으며 구성에 따라 job이 파이프라인에 포함되거나 제외됩니다. 어떤 규칙도 일치하지 않으면 job이 파이프라인에 추가되지 않습니다.

rules는 규칙 배열을 허용합니다. 각 규칙에는 다음 중 하나 이상이 있어야 합니다:

if
changes
exists
when

규칙은 선택적으로 다음과 함께 결합될 수도 있습니다:

allow_failure
needs
variables
interruptible

복잡한 규칙을 위해 여러 키워드를 함께 결합할 수 있습니다.

job이 파이프라인에 추가되는 경우:

if, changes, 또는 exists 규칙이 일치하고 when: on_success (정의하지 않으면 기본값), when: delayed, 또는 when: always로 구성된 경우.
when: on_success, when: delayed, 또는 when: always만 있는 규칙에 도달한 경우.

job이 파이프라인에 추가되지 않는 경우:

어떤 규칙도 일치하지 않는 경우.
규칙이 일치하고 when: never인 경우.

추가 예시는 rules로 job이 실행되는 시기 지정을 참조하세요.

`rules:if`#

rules:if 절을 사용하여 파이프라인에 job을 추가하는 시기를 지정합니다:

if 문이 true이면 파이프라인에 job을 추가합니다.
if 문이 true이지만 when: never와 결합된 경우 파이프라인에 job을 추가하지 않습니다.
if 문이 false이면 다음 rules 항목을 확인합니다 (더 있는 경우).

if 절은 다음을 기반으로 평가됩니다:

일부 예외 사항이 있는 CI/CD 변수 또는 사전 정의된 CI/CD 변수의 값.
rules 실행 흐름을 따르는 순서.

키워드 유형: job별 및 파이프라인별. job의 일부로 사용하여 job 동작을 구성하거나 workflow와 함께 사용하여 파이프라인 동작을 구성할 수 있습니다.

지원되는 값:

CI/CD 변수 표현식.

rules:if 예시:

job:
  script: echo "Hello, 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

추가 세부 정보:

if와 함께 중첩 변수를 사용할 수 없습니다. 자세한 내용은 이슈 327780을 참조하세요.
규칙이 일치하고 when이 정의되지 않은 경우 규칙은 job에 정의된 when을 사용하며 정의되지 않은 경우 기본값은 on_success입니다.
when을 job 수준에서 rules의 when과 혼합할 수 있습니다. rules의 when 구성이 job 수준의 when보다 우선합니다.
script 섹션의 변수와 달리 rules 표현식의 변수는 항상 $VARIABLE 형식입니다.
- include와 함께 rules:if를 사용하여 다른 구성 파일을 조건부로 포함할 수 있습니다.
=~ 및 !~ 표현식의 오른쪽에 있는 CI/CD 변수는 정규 표현식으로 평가됩니다.

관련 항목:

`rules:changes`#

rules:changes를 사용하여 특정 파일의 변경 사항을 확인하여 파이프라인에 job을 추가하는 시기를 지정합니다.

새 브랜치 파이프라인의 경우 또는 Git push 이벤트가 없는 경우 rules: changes는 항상 true로 평가되며 job은 항상 실행됩니다. 태그 파이프라인, 예약된 파이프라인, 수동 파이프라인과 같은 파이프라인은 모두 연결된 Git push 이벤트가 없습니다. 이러한 경우를 처리하려면 파이프라인 ref에 비교할 브랜치를 지정하기 위해 rules: changes: compare_to를 사용합니다.

compare_to를 사용하지 않는 경우 rules: changes는 브랜치 파이프라인 또는 머지 리퀘스트 파이프라인에서만 사용해야 하지만 rules: changes는 새 브랜치를 생성할 때도 true로 평가됩니다. 다음을 사용할 때:

머지 리퀘스트 파이프라인의 경우 rules:changes는 대상 MR 브랜치와 변경 사항을 비교합니다.
브랜치 파이프라인의 경우 rules:changes는 브랜치의 이전 커밋과 변경 사항을 비교합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

다음을 포함하는 배열:

파일 경로. 파일 경로는 CI/CD 변수를 포함할 수 있습니다.
와일드카드 경로:
- 단일 디렉토리의 경우, 예: 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

docker build alternative:
  variables:
    DOCKERFILES_DIR: 'path/to/dockerfiles'
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      changes:
        - $DOCKERFILES_DIR/**/*

이 예시에서:

파이프라인이 머지 리퀘스트 파이프라인이면 Dockerfile과 $DOCKERFILES_DIR/**/*의 파일 변경 사항을 확인합니다.
Dockerfile이 변경되었으면 job을 수동 job으로 파이프라인에 추가하고 job이 트리거되지 않아도 파이프라인이 계속 실행됩니다 (allow_failure: true).
$DOCKERFILES_DIR/**/*의 파일이 변경되었으면 파이프라인에 job을 추가합니다.
나열된 파일이 변경되지 않았으면 어떤 파이프라인에도 어떤 job도 추가하지 않습니다 (when: never와 동일).

추가 세부 정보:

Glob 패턴은 Ruby의 File.fnmatch로 플래그 File::FNM_PATHNAME | File::FNM_DOTMATCH | File::FNM_EXTGLOB을 사용하여 해석됩니다.
성능상의 이유로 GitLab은 changes 패턴 또는 파일 경로에 대해 최대 50,000번의 검사를 수행합니다. 50,000번째 검사 이후에는 패턴화된 glob이 있는 규칙이 항상 일치합니다. 즉, 50,000개 이상의 파일이 변경되었거나 변경된 파일이 50,000개 미만이지만 changes 규칙이 50,000번 이상 확인된 경우 changes 규칙은 항상 일치한다고 가정합니다.
rules:changes 섹션당 최대 50개의 패턴 또는 파일 경로를 정의할 수 있습니다.
changes는 나열된 파일 중 하나라도 변경된 경우 true로 확인됩니다 (OR 연산).
추가 예시는 rules로 job이 실행되는 시기 지정을 참조하세요.
변수와 경로 모두에 $ 문자를 사용할 수 있습니다. 예를 들어 $VAR 변수가 존재하면 그 값이 사용됩니다. 존재하지 않으면 $는 경로의 일부로 해석됩니다.
./, 이중 슬래시 (//) 또는 다른 종류의 상대 경로를 사용하지 마세요. 경로는 정확한 문자열 비교로 일치하며 쉘에서처럼 평가되지 않습니다.

관련 항목:

rules: changes 사용 시 job 또는 파이프라인이 예기치 않게 실행됨.

`rules:changes:paths`#

히스토리

GitLab 15.2에서 도입되었습니다.

rules:changes를 사용하여 특정 파일이 변경된 경우에만 파이프라인에 job을 추가하고 rules:changes:paths를 사용하여 파일을 지정합니다.

rules:changes:paths는 하위 키 없이 rules:changes를 사용하는 것과 동일합니다. 모든 추가 세부 정보 및 관련 항목은 동일합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

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

이 예시에서 두 job의 동작은 동일합니다.

`rules:changes:compare_to`#

히스토리

GitLab 15.3에서 ci_rules_changes_compare라는 플래그와 함께 도입되었습니다. 기본적으로 활성화되어 있습니다.
GitLab 15.5에서 일반 공개되었습니다. 기능 플래그 ci_rules_changes_compare가 제거되었습니다.
CI/CD 변수 지원이 GitLab 17.2에서 도입되었습니다.

rules:changes:compare_to를 사용하여 rules:changes:paths 아래에 나열된 파일의 변경 사항과 비교할 ref를 지정합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있으며 rules:changes:paths와 함께 사용해야 합니다.

지원되는 값:

main, branch1, 또는 refs/heads/branch1과 같은 브랜치 이름.
tag1 또는 refs/tags/tag1과 같은 태그 이름.
2fg31ga14b와 같은 커밋 SHA.

CI/CD 변수는 지원됩니다.

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 job은 Dockerfile이 refs/heads/branch1에 상대적으로 변경되었고 파이프라인 소스가 머지 리퀘스트 이벤트인 경우에만 포함됩니다.

추가 세부 정보:

일부 상황에서 compare_to를 사용하면 예상치 못한 결과가 발생할 수 있습니다:
- 병합 결과 파이프라인에서는 비교 기반이 GitLab이 생성하는 내부 커밋이기 때문입니다.
- 포크된 프로젝트에서는 이슈 424584를 참조하세요.

관련 항목:

rules:changes:compare_to를 사용하여 브랜치가 비어 있는 경우 job 건너뛰기.

`rules:exists`#

히스토리

CI/CD 변수 지원이 GitLab 15.6에서 도입되었습니다.
exists 패턴 또는 파일 경로에 대한 최대 검사 수가 GitLab 17.7에서 10,000에서 50,000으로 증가했습니다.
디렉토리 경로 지원이 GitLab 18.2에서 도입되었습니다.

리포지터리에 특정 파일 또는 디렉토리가 존재할 때 job을 실행하려면 exists를 사용합니다.

키워드 유형: Job 키워드. job의 일부 또는 include에서 사용할 수 있습니다.

지원되는 값:

파일 또는 디렉토리 경로의 배열. 경로는 프로젝트 디렉토리 ($CI_PROJECT_DIR)에 상대적이며 외부로 직접 연결할 수 없습니다. 파일 경로는 glob 패턴과 CI/CD 변수를 사용할 수 있습니다.

rules:exists 예시:

job1:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - exists:
        - Dockerfile

job2:
  variables:
    DOCKERPATH: "**/Dockerfile"
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - exists:
        - $DOCKERPATH

이 예시에서:

job1은 리포지터리의 루트 디렉토리에 Dockerfile이 존재하면 실행됩니다.
job2는 리포지터리 어디에나 Dockerfile이 존재하면 실행됩니다.

추가 세부 정보:

Glob 패턴은 Ruby의 File.fnmatch로 플래그 File::FNM_PATHNAME | File::FNM_DOTMATCH | File::FNM_EXTGLOB을 사용하여 해석됩니다.
성능상의 이유로 GitLab은 exists 패턴 또는 파일 경로에 대해 최대 50,000번의 검사를 수행합니다. 50,000번째 검사 이후에는 패턴화된 glob이 있는 규칙이 항상 일치합니다. 즉, 파일이 50,000개 이상인 프로젝트나 파일이 50,000개 미만이지만 exists 규칙이 50,000번 이상 확인된 경우 exists 규칙은 항상 일치한다고 가정합니다.
- 여러 패턴화된 glob이 있는 경우 제한은 50,000을 glob의 수로 나눈 값입니다. 예를 들어 5개의 패턴화된 glob이 있는 규칙은 파일 제한이 10,000입니다.
rules:exists 섹션당 최대 50개의 패턴 또는 파일 경로를 정의할 수 있습니다.
exists는 나열된 파일 중 하나라도 발견되면 true로 확인됩니다 (OR 연산).
job 수준 rules:exists에서 GitLab은 파이프라인을 실행하는 프로젝트 및 ref에서 파일을 검색합니다. include와 함께 rules:exists 사용 시 GitLab은 include 섹션이 포함된 파일의 프로젝트 및 ref에서 파일 또는 디렉토리를 검색합니다. include 섹션이 포함된 프로젝트는 다음을 사용할 때 파이프라인을 실행하는 프로젝트와 다를 수 있습니다:
- 중첩 포함.
- 컴플라이언스 파이프라인.
rules:exists는 아티팩트의 존재를 검색할 수 없습니다. rules 평가는 job이 실행되고 아티팩트가 가져와지기 전에 발생하기 때문입니다.
디렉토리의 존재를 테스트하려면 경로가 슬래시 (/)로 끝나야 합니다.

`rules:exists:paths`#

히스토리

GitLab 16.11에서 ci_support_rules_exists_paths_and_project라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
GitLab 17.0에서 일반 공개되었습니다. 기능 플래그 ci_support_rules_exists_paths_and_project가 제거되었습니다.

rules:exists:paths는 하위 키 없이 rules:exists를 사용하는 것과 동일합니다. 모든 추가 세부 정보는 동일합니다.

키워드 유형: Job 키워드. job의 일부 또는 include에서 사용할 수 있습니다.

지원되는 값:

파일 경로 배열.

rules:exists:paths 예시:

docker-build-1:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      exists:
        - Dockerfile

docker-build-2:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      exists:
        paths:
          - Dockerfile

이 예시에서 두 job의 동작은 동일합니다.

`rules:exists:project`#

히스토리

GitLab 16.11에서 ci_support_rules_exists_paths_and_project라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
GitLab 17.0에서 일반 공개되었습니다. 기능 플래그 ci_support_rules_exists_paths_and_project가 제거되었습니다.

rules:exists:project를 사용하여 rules:exists:paths 아래에 나열된 파일을 검색할 위치를 지정합니다. rules:exists:paths와 함께 사용해야 합니다.

키워드 유형: Job 키워드. job의 일부 또는 include에서 사용할 수 있으며 rules:exists:paths와 함께 사용해야 합니다.

지원되는 값:

exists:project: 네임스페이스와 그룹을 포함한 전체 프로젝트 경로.
exists:ref: 선택 사항. 파일을 검색하는 데 사용할 커밋 ref. ref는 태그, 브랜치 이름, 또는 SHA일 수 있습니다. 지정하지 않으면 프로젝트의 HEAD로 기본 설정됩니다.

rules:exists:project 예시:

docker build:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - exists:
        paths:
          - Dockerfile
        project: my-group/my-project
        ref: v1.0.0

이 예시에서 docker build job은 Dockerfile이 v1.0.0 태그에 커밋된 my-group/my-project 프로젝트에 존재할 때만 포함됩니다.

`rules:when`#

rules:when을 단독으로 또는 다른 규칙의 일부로 사용하여 파이프라인에 job을 추가하는 조건을 제어합니다. rules:when은 when과 유사하지만 입력 옵션이 약간 다릅니다.

rules:when 규칙이 if, changes, 또는 exists와 결합되지 않은 경우 job의 규칙을 평가할 때 도달하면 항상 일치합니다.

키워드 유형: job별. job의 일부로만 사용할 수 있습니다.

지원되는 값:

on_success (기본값): 이전 stage의 job이 실패하지 않는 경우에만 job을 실행합니다.
on_failure: 이전 stage에서 하나 이상의 job이 실패한 경우에만 job을 실행합니다.
never: 이전 stage의 job 상태에 관계없이 job을 실행하지 않습니다.
always: 이전 stage의 job 상태에 관계없이 job을 실행합니다.
manual: job을 수동 job으로 파이프라인에 추가합니다. allow_failure의 기본값이 false로 변경됩니다.
delayed: job을 지연 job으로 파이프라인에 추가합니다.

rules:when 예시:

job1:
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
    - if: $CI_COMMIT_REF_NAME =~ /feature/
      when: delayed
    - when: manual
  script:
    - echo

이 예시에서 job1은 다음 파이프라인에 추가됩니다:

기본 브랜치의 경우 when이 정의되지 않을 때의 기본 동작인 when: on_success를 사용합니다.
feature 브랜치의 경우 지연 job으로.
다른 모든 경우에는 수동 job으로.

추가 세부 정보:

on_success 및 on_failure에 대한 job 상태를 평가할 때:
- 이전 stage에서 allow_failure: true가 있는 job은 실패했더라도 성공한 것으로 간주됩니다.
- 이전 stage에서 건너뛴 job, 예를 들어 시작되지 않은 수동 job은 성공한 것으로 간주됩니다.
rules:when: manual을 사용하여 수동 job을 추가할 때:
- allow_failure는 기본적으로 false가 됩니다. 이 기본값은 수동 job을 추가하기 위해 when: manual을 사용하는 것과 반대입니다.
- rules 외부에서 정의된 when: manual과 동일한 동작을 달성하려면 rules: allow_failure를 true로 설정합니다.

`rules:allow_failure`#

rules에서 allow_failure: true를 사용하여 파이프라인을 중지하지 않고 job이 실패하도록 허용합니다.

allow_failure: true를 수동 job과 함께 사용할 수도 있습니다. 파이프라인은 수동 job의 결과를 기다리지 않고 계속 실행됩니다. rules에서 when: manual과 결합된 allow_failure: false는 파이프라인이 계속 진행되기 전에 수동 job이 실행될 때까지 기다리게 합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

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

규칙이 일치하면 job은 allow_failure: true가 있는 수동 job입니다.

추가 세부 정보:

규칙 수준의 rules:allow_failure는 job 수준의 allow_failure를 재정의하며 특정 규칙이 job을 트리거할 때만 적용됩니다.

`rules:needs`#

히스토리

GitLab 16.0에서 introduce_rules_with_needs라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
GitLab 16.2에서 일반 공개되었습니다. 기능 플래그 introduce_rules_with_needs가 제거되었습니다.

rules에서 needs를 사용하여 특정 조건에 대한 job의 needs를 업데이트합니다. 조건이 규칙과 일치할 때 job의 needs 구성이 규칙의 needs로 완전히 대체됩니다.

키워드 유형: job별. job의 일부로만 사용할 수 있습니다.

지원되는 값:

문자열로 된 job 이름 배열.
추가 속성이 있는 job 이름의 해시 (선택 사항).
빈 배열 ([]), 특정 조건이 충족될 때 job needs를 없음으로 설정합니다.

rules:needs 예시:

build-dev:
  stage: build
  rules:
    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH
  script: echo "Feature branch, so building dev version..."

build-prod:
  stage: build
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  script: echo "Default branch, so building prod version..."

tests:
  stage: test
  rules:
    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH
      needs: ['build-dev']
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      needs: ['build-prod']
  script: echo "Running dev specs by default, or prod specs when default branch..."

이 예시에서:

파이프라인이 기본 브랜치가 아닌 브랜치에서 실행되어 첫 번째 조건과 규칙이 일치하면 specs job은 build-dev job이 필요합니다.
파이프라인이 기본 브랜치에서 실행되어 두 번째 조건과 규칙이 일치하면 specs job은 build-prod job이 필요합니다.

추가 세부 정보:

rules의 needs는 job 수준에서 정의된 needs를 재정의합니다. 재정의 시 동작은 job 수준 needs와 동일합니다.
rules의 needs는 artifacts 및 optional을 허용할 수 있습니다.

`rules:variables`#

rules에서 variables를 사용하여 특정 조건에 대한 변수를 정의합니다.

키워드 유형: job별. job의 일부로만 사용할 수 있습니다.

지원되는 값:

VARIABLE-NAME: value 형식의 변수 해시.

rules:variables 예시:

job:
  variables:
    DEPLOY_VARIABLE: "default-deploy"
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      variables:                              # Override DEPLOY_VARIABLE defined
        DEPLOY_VARIABLE: "deploy-production"  # at the job level.
    - if: $CI_COMMIT_REF_NAME =~ /feature/
      variables:
        IS_A_FEATURE: "true"                  # Define a new variable.
  script:
    - echo "Run script with $DEPLOY_VARIABLE as an argument"
    - echo "Run another script if $IS_A_FEATURE exists"

`rules:interruptible`#

히스토리

GitLab 16.10에서 도입되었습니다.

rules에서 interruptible을 사용하여 특정 조건에 대한 job의 interruptible 값을 업데이트합니다.

키워드 유형: job별. job의 일부로만 사용할 수 있습니다.

지원되는 값:

true 또는 false.

rules:interruptible 예시:

job:
  script: echo "Hello, Rules!"
  interruptible: true
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      interruptible: false  # Override interruptible defined at the job level.
    - when: on_success

추가 세부 정보:

규칙 수준의 rules:interruptible은 job 수준의 interruptible을 재정의하며 특정 규칙이 job을 트리거할 때만 적용됩니다.

`run`#

히스토리

GitLab 17.3에서 pipeline_run_keyword라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다. GitLab Runner 17.1이 필요합니다.
기능 플래그 pipeline_run_keyword가 GitLab 17.5에서 제거되었습니다.

Note

이 기능은 테스트에 사용할 수 있지만 프로덕션 사용에는 준비되지 않았습니다.

run을 사용하여 job에서 실행할 일련의 steps를 정의합니다. 각 step은 스크립트 또는 사전 정의된 step일 수 있습니다.

선택적 환경 변수와 입력값을 제공할 수도 있습니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

해시 배열, 각 해시는 다음 가능한 키가 있는 step을 나타냅니다:
- name: step의 이름을 나타내는 문자열.
- script: 실행할 쉘 명령이 포함된 문자열.
- step: 실행할 사전 정의된 step을 식별하는 문자열.
- env: 선택 사항. 이 step에 특정한 환경 변수의 해시.
- inputs: 선택 사항. 사전 정의된 step의 입력 파라미터 해시.

각 배열 항목에는 name과 script 또는 step 중 하나 (둘 다는 안 됨)가 있어야 합니다.

run 예시:

job:
  run:
    - name: 'hello_steps'
      script: 'echo "hello from step1"'
    - name: 'bye_steps'
      step: gitlab.com/gitlab-org/ci-cd/runner-tools/echo-step@main
      inputs:
        echo: 'bye steps!'
      env:
        var1: 'value 1'

이 예시에서 job에는 두 가지 step이 있습니다:

hello_steps는 echo 쉘 명령을 실행합니다.
bye_steps는 환경 변수와 입력 파라미터가 있는 사전 정의된 step을 사용합니다.

추가 세부 정보:

step에는 script 또는 step 키 중 하나만 있을 수 있으며 둘 다는 안 됩니다.
run 구성은 기존 script, after_script 또는 before_script 키워드와 함께 사용할 수 없습니다.
여러 줄 스크립트는 YAML 블록 스칼라 구문을 사용하여 정의할 수 있습니다.

`script`#

script를 사용하여 러너가 실행할 명령을 지정합니다.

trigger job을 제외한 모든 job에는 script 키워드가 필요합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값: 다음을 포함하는 배열:

단일 줄 명령.
여러 줄로 분할된 긴 명령.
YAML 앵커.

CI/CD 변수는 지원됩니다.

script 예시:

job1:
  script: "bundle exec rspec"

job2:
  script:
    - uname -a
    - bundle exec rspec

추가 세부 정보:

script에서 이러한 특수 문자를 사용할 때는 작은따옴표 (') 또는 큰따옴표 (")를 사용해야 합니다.

관련 항목:

0이 아닌 종료 코드를 무시할 수 있습니다.
작업 로그를 더 쉽게 검토할 수 있도록 script에 색상 코드를 사용합니다.
작업 로그 출력을 단순화하기 위해 사용자 정의 축소 가능한 섹션을 생성합니다.

`secrets`#

secrets를 사용하여 다음을 위한 CI/CD 시크릿을 지정합니다:

외부 시크릿 제공자에서 가져오기.
job에서 CI/CD 변수로 사용 가능하게 하기 (기본적으로 file 유형).

`secrets:vault`#

히스토리

generic 엔진 옵션이 GitLab Runner 16.11에서 도입되었습니다.

secrets:vault를 사용하여 HashiCorp Vault에서 제공하는 시크릿을 지정합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

engine:name: 시크릿 엔진의 이름. kv-v2 (기본값), kv-v1, 또는 generic 중 하나일 수 있습니다.
engine:path: 시크릿 엔진의 경로.
path: 시크릿의 경로.
field: 비밀번호가 저장된 필드 이름.

secrets:vault 예시:

모든 세부 정보를 명시적으로 지정하고 KV-V2 시크릿 엔진을 사용하려면:

job:
  secrets:
    DATABASE_PASSWORD:  # Store the path to the secret in this CI/CD variable
      vault:  # Translates to secret: `ops/data/production/db`, field: `password`
        engine:
          name: kv-v2
          path: ops
        path: production/db
        field: password

이 구문을 단축할 수 있습니다. 단축 구문을 사용하면 engine:name과 engine:path가 모두 kv-v2로 기본 설정됩니다:

job:
  secrets:
    DATABASE_PASSWORD:  # Store the path to the secret in this CI/CD variable
      vault: production/db/password  # Translates to secret: `kv-v2/data/production/db`, field: `password`

단축 구문에서 사용자 정의 시크릿 엔진 경로를 지정하려면 @로 시작하는 접미사를 추가합니다:

job:
  secrets:
    DATABASE_PASSWORD:  # Store the path to the secret in this CI/CD variable
      vault: production/db/password@ops  # Translates to secret: `ops/data/production/db`, field: `password`

`secrets:gcp_secret_manager`#

히스토리

GitLab 16.8 및 GitLab Runner 16.8에서 도입되었습니다.

secrets:gcp_secret_manager를 사용하여 GCP Secret Manager에서 제공하는 시크릿을 지정합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

name: 시크릿의 이름.
version: 시크릿의 버전.

secrets:gcp_secret_manager 예시:

job:
  secrets:
    DATABASE_PASSWORD:
      gcp_secret_manager:
        name: 'test'
        version: 2

관련 항목:

GitLab CI/CD에서 GCP Secret Manager 시크릿 사용.

`secrets:azure_key_vault`#

히스토리

GitLab 16.3 및 GitLab Runner 16.3에서 도입되었습니다.

secrets:azure_key_vault를 사용하여 Azure Key Vault에서 제공하는 시크릿을 지정합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

name: 시크릿의 이름.
version: 시크릿의 버전.

secrets:azure_key_vault 예시:

job:
  secrets:
    DATABASE_PASSWORD:
      azure_key_vault:
        name: 'test'
        version: 'test'

관련 항목:

GitLab CI/CD에서 Azure Key Vault 시크릿 사용.

`secrets:file`#

secrets:file을 사용하여 시크릿을 file 또는 variable 유형 CI/CD 변수로 저장할지 구성합니다.

기본적으로 시크릿은 job에 file 유형 CI/CD 변수로 전달됩니다. 시크릿의 값은 파일에 저장되고 변수에는 파일 경로가 포함됩니다.

소프트웨어가 file 유형 CI/CD 변수를 사용할 수 없는 경우 시크릿 값을 변수에 직접 저장하려면 file: false를 설정합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

true (기본값) 또는 false.

secrets:file 예시:

job:
  secrets:
    DATABASE_PASSWORD:
      vault: production/db/password@ops
      file: false

추가 세부 정보:

file 키워드는 CI/CD 변수의 설정이며 vault 섹션이 아닌 CI/CD 변수 이름 아래에 중첩되어야 합니다.

`secrets:token`#

히스토리

JSON Web Token (JWT) 액세스 제한 설정에 의해 제어되는 GitLab 15.8에서 도입되었습니다.
GitLab 16.0에서 항상 사용 가능하게 되었으며 JSON Web Token (JWT) 액세스 제한 설정이 제거되었습니다.

secrets:token을 사용하여 토큰의 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 키워드가 설정되지 않았고 토큰이 하나만 정의된 경우 정의된 토큰이 자동으로 사용됩니다.
토큰이 두 개 이상 정의된 경우 token 키워드를 설정하여 사용할 토큰을 지정해야 합니다. 사용할 토큰을 지정하지 않으면 job이 실행될 때마다 어떤 토큰이 사용되는지 예측할 수 없습니다.

`services`#

services를 사용하여 스크립트가 성공적으로 실행되는 데 필요한 추가 Docker 이미지를 지정합니다. services 이미지는 image 키워드에 지정된 이미지에 연결됩니다.

job 구성과 기본 구성은 함께 병합되지 않습니다. 파이프라인에 default:services가 정의되어 있고 job에도 services가 있는 경우 job 구성이 우선하며 기본 구성은 사용되지 않습니다.

Warning

서비스 간 네트워킹을 활성화하려면 FF_NETWORK_PER_BUILD를 true로 설정하세요. 이 플래그 없이는 서비스가 제대로 작동하지 않을 수 있습니다. 자세한 내용은 기능 플래그를 참조하세요.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값: 필요한 경우 레지스트리 경로를 포함한 서비스 이미지 이름, 다음 형식 중 하나로:

<image-name> (latest 태그와 함께 <image-name> 사용과 동일)
<image-name>:<tag>
<image-name>@<digest>

CI/CD 변수는 지원됩니다, 단 alias에는 지원되지 않습니다. alias를 동적으로 사용자 정의하려면 CI/CD 입력값을 대신 사용하세요.

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은 job에 대한 두 컨테이너를 시작합니다:

스크립트 명령을 실행하는 Ruby 컨테이너.
PostgreSQL 컨테이너. Ruby 컨테이너의 스크립트 명령은 db-postgres 호스트 이름에서 PostgreSQL 데이터베이스에 연결할 수 있습니다.

추가 세부 정보:

default 섹션이 아닌 최상위 수준에서 services를 사용하는 것은 더 이상 사용되지 않습니다.

관련 항목:

`services:name`#

서비스에 사용할 이미지의 전체 이름.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값: 필요한 경우 레지스트리 경로를 포함한 서비스 이미지 이름, 다음 형식 중 하나로:

<image-name> (latest 태그와 함께 <image-name> 사용과 동일)
<image-name>:<tag>
<image-name>@<digest>

CI/CD 변수는 지원됩니다.

services:name 예시:

services:
  - name: postgres:11.7
  - name: registry.example.com/my-org/custom-service:latest

추가 세부 정보:

여러 동일한 서비스 이미지를 사용하거나 서비스 이미지 이름이 긴 경우 고유한 이름 별칭을 정의하려면 alias를 사용합니다.
entrypoint, command 또는 variables와 같은 다른 서비스 옵션과 함께 사용할 때 name 키워드가 필요합니다.
자세한 내용은 서비스에 액세스하기를 참조하세요.

`services:alias`#

히스토리

GitLab Runner 17.9에서 도입되었습니다.

job의 컨테이너에서 서비스에 액세스하기 위한 추가 별칭.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값: 공백 또는 쉼표로 구분된 하나 이상의 별칭이 있는 문자열.

services:alias 예시:

services:
  - name: postgres:11.7
    alias: db,postgres,pg
  - name: mysql:latest
    alias: mysql-1

추가 세부 정보:

여러 별칭은 공백 또는 쉼표로 구분할 수 있습니다.
자세한 내용은 서비스에 액세스하기 및 Kubernetes executor에 대한 서비스 컨테이너 이름으로 별칭 사용을 참조하세요.

`services:docker`#

히스토리

GitLab 16.7에서 도입되었습니다. GitLab Runner 16.7 이상이 필요합니다.
user 입력 옵션이 GitLab 16.8에서 도입되었습니다.

services:docker를 사용하여 GitLab Runner의 Docker executor에 옵션을 전달합니다.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

Docker executor에 대한 옵션의 해시, 다음을 포함할 수 있습니다:

platform: 가져올 이미지의 아키텍처를 선택합니다. 지정하지 않으면 기본값은 호스트 러너와 동일한 플랫폼입니다.
user: 컨테이너를 실행할 때 사용할 사용자 이름 또는 UID를 지정합니다.

services:docker 예시:

arm-sql-job:
  script: echo "Run sql tests in service container"
  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:kubernetes`#

히스토리

GitLab 18.0에서 도입되었습니다. GitLab Runner 17.11 이상이 필요합니다.
user 입력 옵션이 GitLab Runner 17.11에서 도입되었습니다.
user 입력 옵션이 GitLab 18.0에서 uid:gid 형식을 지원하도록 확장되었습니다.

services:kubernetes를 사용하여 GitLab Runner Kubernetes executor에 옵션을 전달합니다.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

Kubernetes executor에 대한 옵션의 해시, 다음을 포함할 수 있습니다:

user: 컨테이너가 실행될 때 사용할 사용자 이름 또는 UID를 지정합니다. UID:GID 형식을 사용하여 GID를 설정할 수도 있습니다.

UID만 사용하는 services:kubernetes 예시:

arm-sql-job:
  script: echo "Run sql tests"
  image: ruby:2.6
  services:
    - name: super/sql:experimental
      kubernetes:
        user: "1001"

UID와 GID 모두 사용하는 services:kubernetes 예시:

arm-sql-job:
  script: echo "Run sql tests"
  image: ruby:2.6
  services:
    - name: super/sql:experimental
      kubernetes:
        user: "1001:1001"

`services:entrypoint`#

컨테이너의 엔트리포인트로 실행할 명령 또는 스크립트.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값: 엔트리포인트 명령을 나타내는 문자열 배열.

services:entrypoint 예시:

services:
  - name: my-postgres:11.7
    entrypoint: ["/usr/local/bin/db-postgres"]

`services:command`#

컨테이너의 명령으로 사용해야 하는 명령 또는 스크립트.

이미지 이름 뒤에 Docker에 전달되는 인수로 변환됩니다. 구문은 각 쉘 토큰이 배열의 별도 문자열인 Dockerfile CMD 지시어와 유사합니다.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값: 명령을 나타내는 문자열 배열.

services:command 예시:

services:
  - name: super/sql:latest
    command: ["/usr/bin/super-sql", "run"]

`services:variables`#

서비스에만 전달되는 추가 환경 변수. 서비스 변수는 서비스 컨테이너에만 전달되며 job 컨테이너에서는 사용할 수 없습니다.

구문은 job 변수와 동일합니다.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값: 환경 변수 이름과 값의 해시.

services:variables 예시:

services:
  - name: postgres:11.7
    alias: db
    variables:
      POSTGRES_DB: "my_custom_db"
      POSTGRES_USER: "postgres"
      POSTGRES_PASSWORD: "example"
      PGDATA: "/var/lib/postgresql/data"

추가 세부 정보:

서비스 변수는 자체를 참조할 수 없으며 변수 확장 또는 보간을 지원하지 않습니다.
job 또는 파이프라인 수준에서 정의된 변수는 서비스에 자동으로 전달됩니다. 자세한 내용은 서비스에 CI/CD 변수 전달을 참조하세요.
서비스 변수는 정의된 특정 서비스에서만 사용할 수 있습니다.

`services:pull_policy`#

히스토리

GitLab 15.1에서 ci_docker_image_pull_policy라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
GitLab 15.2에서 GitLab.com 및 GitLab Self-Managed에서 활성화되었습니다.
GitLab 15.4에서 일반 공개되었습니다. 기능 플래그 ci_docker_image_pull_policy가 제거되었습니다.

러너가 Docker 이미지를 가져오는 데 사용하는 풀 정책. GitLab Runner 15.1 이상이 필요합니다.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

단일 풀 정책 또는 배열의 여러 풀 정책. always, if-not-present, 또는 never일 수 있습니다.

services:pull_policy 예시:

job1:
  script: echo "A single pull policy."
  services:
    - name: postgres:11.6
      pull_policy: if-not-present

job2:
  script: echo "Multiple pull policies."
  services:
    - name: postgres:11.6
      pull_policy: [always, if-not-present]

추가 세부 정보:

러너가 정의된 풀 정책을 지원하지 않으면 job이 다음과 유사한 오류와 함께 실패합니다: ERROR: Job failed (system failure): the configured PullPolicies ([always]) are not allowed by AllowedPullPolicies ([never]).

관련 항목:

`stage`#

stage를 사용하여 job이 실행되는 stage를 정의합니다. 동일한 stage의 job은 병렬로 실행될 수 있습니다 (추가 세부 정보 참조).

stage가 정의되지 않으면 job은 기본적으로 test stage를 사용합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값: 다음일 수 있는 문자열:

기본 stage.
사용자 정의 stage.

stage 예시:

stages:
  - build
  - test
  - deploy

job1:
  stage: build
  script:
    - echo "This job compiles code."

job2:
  stage: test
  script:
    - echo "This job tests the compiled code. It runs when the build stage completes."

job3:
  script:
    - echo "This job also runs in the test stage."

job4:
  stage: deploy
  script:
    - echo "This job deploys the code. It runs when the test stage completes."
  environment: production

추가 세부 정보:

stage 이름은 255자 이하여야 합니다.
Job은 서로 다른 러너에서 실행되는 경우 병렬로 실행될 수 있습니다.
러너가 하나만 있는 경우 러너의 concurrent 설정 이 1보다 크면 Job이 병렬로 실행될 수 있습니다.

`stage: .pre`#

.pre stage를 사용하면 파이프라인의 시작 부분에서 Job을 실행할 수 있습니다. 기본적으로 .pre는 파이프라인의 첫 번째 stage입니다. 사용자 정의 stage는 .pre 이후에 실행됩니다. stages에 .pre를 정의할 필요가 없습니다.

파이프라인에 .pre 또는 .post stage의 Job만 포함된 경우 파이프라인이 실행되지 않습니다. 다른 stage에 적어도 하나의 Job이 있어야 합니다.

키워드 유형: Job의 stage 키워드와 함께만 사용할 수 있습니다.

stage: .pre 예시:

stages:
  - build
  - test

job1:
  stage: build
  script:
    - echo "This job runs in the build stage."

first-job:
  stage: .pre
  script:
    - echo "This job runs in the .pre stage, before all other stages."

job2:
  stage: test
  script:
    - echo "This job runs in the test stage."

추가 세부 정보:

파이프라인에 needs: []인 Job과 .pre stage의 Job이 있는 경우, 파이프라인이 생성되는 즉시 모두 시작됩니다. needs: []인 Job은 stage 설정을 무시하고 즉시 시작됩니다.
파이프라인 실행 정책은 .pre 이전에 실행되는 .pipeline-policy-pre stage를 정의할 수 있습니다.

`stage: .post`#

.post stage를 사용하면 파이프라인의 끝에서 Job을 실행할 수 있습니다. 기본적으로 .post는 파이프라인의 마지막 stage입니다. 사용자 정의 stage는 .post 이전에 실행됩니다. stages에 .post를 정의할 필요가 없습니다.

파이프라인에 .pre 또는 .post stage의 Job만 포함된 경우 파이프라인이 실행되지 않습니다. 다른 stage에 적어도 하나의 Job이 있어야 합니다.

키워드 유형: Job의 stage 키워드와 함께만 사용할 수 있습니다.

stage: .post 예시:

stages:
  - build
  - test

job1:
  stage: build
  script:
    - echo "This job runs in the build stage."

last-job:
  stage: .post
  script:
    - echo "This job runs in the .post stage, after all other stages."

job2:
  stage: test
  script:
    - echo "This job runs in the test stage."

추가 세부 정보:

파이프라인 실행 정책은 .post 이후에 실행되는 .pipeline-policy-post stage를 정의할 수 있습니다.

`tags`#

tags를 사용하여 프로젝트에서 사용 가능한 모든 러너 목록에서 특정 러너를 선택합니다.

러너를 등록할 때 러너의 태그(예: ruby, postgres, development)를 지정할 수 있습니다. Job을 선택하고 실행하려면 러너에 Job에 나열된 모든 태그가 할당되어 있어야 합니다.

Job 설정과 기본 설정은 병합되지 않습니다. 파이프라인에 default:tags가 정의되어 있고 Job에도 tags가 있는 경우, Job 설정이 우선하며 기본 설정은 사용되지 않습니다.

키워드 유형: Job 키워드. Job의 일부로만 사용하거나 default 섹션에서 사용할 수 있습니다.

지원되는 값:

대소문자를 구분하는 태그 이름 배열.
CI/CD 변수는 지원됩니다.

tags 예시:

job:
  tags:
    - ruby
    - postgres

이 예시에서 ruby와 postgres 태그가 모두 있는 러너만 Job을 실행할 수 있습니다.

추가 세부 정보:

태그 수는 50개 미만이어야 합니다.

관련 주제:

`timeout`#

timeout을 사용하여 특정 Job의 타임아웃을 설정합니다. Job이 타임아웃보다 오래 실행되면 Job이 실패합니다.

Job 수준 타임아웃은 프로젝트 수준 타임아웃보다 길 수 있지만, 러너의 타임아웃보다 길 수 없습니다.

키워드 유형: Job 키워드. Job의 일부로만 사용하거나 default 섹션에서 사용할 수 있습니다.

지원되는 값: 자연어로 작성된 기간. 예를 들어 다음은 모두 동일합니다:

3600 seconds
60 minutes
one hour

timeout 예시:

build:
  script: build.sh
  timeout: 3 hours 30 minutes

test:
  script: rspec
  timeout: 3h 30m

추가 세부 정보:

timeout 키워드는 default 설정에서 지원되지 않습니다. 대신 개별 job 설정에서 timeout을 정의하세요. 자세한 내용은 이슈 213634를 참조하세요.

`trigger`#

히스토리

GitLab 16.4에서 environment 지원이 도입되었습니다.

trigger를 사용하여 Job이 다음 중 하나인 다운스트림 파이프라인을 시작하는 "트리거 Job"임을 선언합니다:

트리거 Job은 제한된 GitLab CI/CD 설정 키워드 세트만 사용할 수 있습니다. 트리거 Job에서 사용 가능한 키워드:

allow_failure.
extends.
needs, 단 needs:project는 제외.
only 및 except.
parallel.
rules.
stage.
trigger.
variables.
when (on_success, on_failure, always 값만 허용).
resource_group.
environment.

키워드 유형: Job 키워드. Job의 일부로만 사용할 수 있습니다.

지원되는 값:

멀티 프로젝트 파이프라인의 경우 다운스트림 프로젝트 경로. CI/CD 변수는 GitLab 15.3 이상에서 지원되지만, Job 전용 변수는 지원되지 않습니다. 또는 trigger:project를 사용합니다.
자식 파이프라인의 경우 trigger:include를 사용합니다.

trigger 예시:

trigger-multi-project-pipeline:
  trigger: my-group/my-project

추가 세부 정보:

같은 Job에서 trigger와 함께 when:manual을 사용할 수 있지만, API를 사용하여 when:manual 트리거 Job을 시작할 수 없습니다. 자세한 내용은 이슈 284086을 참고하세요.
수동 트리거 Job을 실행하기 전에 CI/CD 변수를 수동으로 지정할 수 없습니다.
최상위 variables 섹션(전역)이나 트리거 Job에 정의된 CI/CD 변수는 트리거 변수로 다운스트림 파이프라인에 전달됩니다.
파이프라인 변수는 기본적으로 다운스트림 파이프라인에 전달되지 않습니다. trigger:forward를 사용하여 이러한 변수를 다운스트림 파이프라인에 전달합니다.
Job 전용 변수는 트리거 Job에서 사용할 수 없습니다.
러너의 config.toml에 정의된 환경 변수는 트리거 Job에서 사용할 수 없으며 다운스트림 파이프라인에 전달되지 않습니다.
트리거 Job에서 needs:pipeline:job을 사용할 수 없습니다.

관련 주제:

멀티 프로젝트 파이프라인 설정 예시.
특정 브랜치, 태그 또는 커밋의 파이프라인을 실행하려면 트리거 토큰을 사용하여 파이프라인 트리거 API로 인증할 수 있습니다. 트리거 토큰은 trigger 키워드와 다릅니다.

`trigger:inputs`#

히스토리

GitLab 17.11에서 도입되었습니다.

다운스트림 파이프라인 설정이 spec:inputs를 사용하는 경우 trigger:inputs를 사용하여 멀티 프로젝트 파이프라인의 inputs를 설정합니다.

trigger:inputs 예시:

trigger:
  - project: 'my-group/my-project'
    inputs:
      website: "My website"

`trigger:include`#

trigger:include를 사용하여 Job이 자식 파이프라인을 시작하는 "트리거 Job"임을 선언합니다.

키워드 유형: Job 키워드. Job의 일부로만 사용할 수 있습니다.

지원되는 값:

자식 파이프라인 설정 파일 경로.

trigger:include 예시:

trigger-child-pipeline:
  trigger:
    include: path/to/child-pipeline.gitlab-ci.yml

추가 세부 정보:

다음을 사용합니다:

trigger:include:artifact: 동적 자식 파이프라인 트리거.
trigger:include:inputs: 다운스트림 파이프라인 설정이 spec:inputs를 사용하는 경우 inputs 설정.
trigger:include:local: 다음의 경우 자식 파이프라인 설정 파일 경로:
- 여러 자식 파이프라인 설정 파일 결합.
- trigger:include:inputs와 결합하여 자식 파이프라인에 inputs 전달. 예:
```
staging-job:
  trigger:
    include:
      - local: path/to/child-pipeline.yml
        inputs:
          environment: staging
```
trigger:include:project: 다른 프로젝트의 설정 파일로 자식 파이프라인 트리거. 파일에 추가 include 항목이 있는 경우 GitLab은 파일을 호스팅하는 프로젝트가 아닌 파이프라인을 실행하는 프로젝트에서 파일을 찾습니다.
trigger:include:template: CI/CD 템플릿으로 자식 파이프라인 트리거.

관련 주제:

자식 파이프라인 설정 예시.

`trigger:include:inputs`#

히스토리

GitLab 17.11에서 도입되었습니다.

다운스트림 파이프라인 설정이 spec:inputs를 사용하는 경우 trigger:include:inputs를 사용하여 자식 파이프라인의 inputs를 설정합니다.

trigger:inputs 예시:

trigger-job:
  trigger:
    include:
      - local: path/to/child-pipeline.yml
        inputs:
          website: "My website"

`trigger:project`#

trigger:project를 사용하여 Job이 멀티 프로젝트 파이프라인을 시작하는 "트리거 Job"임을 선언합니다.

기본적으로 멀티 프로젝트 파이프라인은 기본 브랜치에 대해 트리거됩니다. trigger:branch를 사용하여 다른 브랜치를 지정합니다.

키워드 유형: Job 키워드. Job의 일부로만 사용할 수 있습니다.

지원되는 값:

다운스트림 프로젝트 경로. CI/CD 변수는 GitLab 15.3 이상에서 지원되지만, Job 전용 변수는 지원되지 않습니다.

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`#

히스토리

GitLab 18.2에서 strategy:mirror 옵션이 도입되었습니다.

trigger:strategy를 사용하여 다운스트림 파이프라인이 완료될 때까지 trigger Job이 기다린 후 success로 표시되도록 합니다.

이 동작은 다운스트림 파이프라인이 생성되는 즉시 trigger Job이 success로 표시되는 기본 동작과 다릅니다.

이 설정은 파이프라인 실행을 병렬이 아닌 선형으로 만듭니다.

지원되는 값:

mirror: 다운스트림 파이프라인의 상태를 정확히 미러링합니다.
depend: 권장하지 않음, 대신 mirror를 사용합니다. 트리거 Job 상태는 다운스트림 파이프라인 상태에 따라 failed, success 또는 running을 표시합니다. 추가 세부 정보를 참고하세요.

trigger:strategy 예시:

trigger_job:
  trigger:
    include: path/to/child-pipeline.yml
    strategy: mirror

이 예시에서 이후 stage의 Job은 트리거된 파이프라인이 성공적으로 완료될 때까지 기다린 후 시작됩니다.

추가 세부 정보:

다운스트림 파이프라인의 선택적 수동 Job은 다운스트림 파이프라인이나 업스트림 트리거 Job의 상태에 영향을 주지 않습니다. 다운스트림 파이프라인은 선택적 수동 Job을 실행하지 않고도 성공적으로 완료될 수 있습니다.
기본적으로 이후 stage의 Job은 트리거 Job이 완료될 때까지 시작되지 않습니다.
다운스트림 파이프라인의 차단 수동 Job은 트리거 Job이 성공 또는 실패로 표시되기 전에 실행되어야 합니다.
strategy:depend 사용 시(더 이상 권장하지 않음, 대신 strategy:mirror 사용):
- 수동 Job으로 인해 다운스트림 파이프라인 상태가 waiting for manual action([status_manual])인 경우 트리거 Job은 running([status_running])을 표시합니다.
- 다운스트림 파이프라인에 실패한 Job이 있지만 해당 Job이 allow_failure: true를 사용하는 경우, 다운스트림 파이프라인은 성공으로 간주되고 트리거 Job은 success를 표시합니다.

`trigger:forward`#

히스토리

GitLab 15.1에서 일반 공개되었습니다. 기능 플래그 ci_trigger_forward_variables가 제거되었습니다.

trigger:forward를 사용하여 다운스트림 파이프라인에 전달할 항목을 지정합니다. 부모-자식 파이프라인과 멀티 프로젝트 파이프라인 모두에 전달할 항목을 제어할 수 있습니다.

전달된 변수는 중첩된 다운스트림 파이프라인에서 기본적으로 다시 전달되지 않습니다. 단, 중첩된 다운스트림 트리거 Job에서도 trigger:forward를 사용하는 경우는 예외입니다.

지원되는 값:

yaml_variables: true(기본값) 또는 false. true이면 트리거 Job에 정의된 변수가 다운스트림 파이프라인에 전달됩니다.
pipeline_variables: true 또는 false(기본값). true이면 파이프라인 변수가 다운스트림 파이프라인에 전달됩니다.

trigger:forward 예시:

CI/CD 변수 MYVAR = my value를 사용하여 이 파이프라인을 수동으로 실행합니다:

variables: # default variables for each job
  VAR: value

---

# Default behavior:
---

# - VAR is passed to the child
---

# - MYVAR is not passed to the child
child1:
  trigger:
    include: .child-pipeline.yml

---

# Forward pipeline variables:
---

# - VAR is passed to the child
---

# - MYVAR is passed to the child
child2:
  trigger:
    include: .child-pipeline.yml
    forward:
      pipeline_variables: true

---

# Do not forward YAML variables:
---

# - VAR is not passed to the child
---

# - MYVAR is not passed to the child
child3:
  trigger:
    include: .child-pipeline.yml
    forward:
      yaml_variables: false

추가 세부 정보:

trigger:forward로 다운스트림 파이프라인에 전달된 CI/CD 변수는 파이프라인 변수이며 높은 우선순위를 가집니다. 다운스트림 파이프라인에 같은 이름의 변수가 정의되어 있으면 해당 변수는 일반적으로 전달된 변수에 의해 덮어씌워집니다.

`when`#

when을 사용하여 Job이 실행되는 조건을 설정합니다. Job에 정의되지 않은 경우 기본값은 when: on_success입니다.

키워드 유형: Job 키워드. Job의 일부로 사용할 수 있습니다. when: always와 when: never는 workflow:rules에서도 사용할 수 있습니다.

지원되는 값:

on_success(기본값): 이전 stage의 Job이 실패하지 않은 경우에만 Job을 실행합니다.
on_failure: 이전 stage에서 적어도 하나의 Job이 실패한 경우에만 Job을 실행합니다.
never: 이전 stage의 Job 상태에 관계없이 Job을 실행하지 않습니다. rules 섹션이나 workflow: rules에서만 사용할 수 있습니다.
always: 이전 stage의 Job 상태에 관계없이 Job을 실행합니다.
manual: Job을 수동 Job으로 파이프라인에 추가합니다.
delayed: Job을 지연 Job으로 파이프라인에 추가합니다.

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을 실행합니다.

추가 세부 정보:

on_success와 on_failure의 Job 상태 평가 시:
- 이전 stage에서 allow_failure: true인 Job은 실패하더라도 성공으로 간주됩니다.
- 이전 stage에서 건너뛴 Job(예: 시작되지 않은 수동 Job)은 성공으로 간주됩니다.
when: manual인 경우 allow_failure의 기본값은 true입니다. rules:when: manual에서는 기본값이 false로 변경됩니다.

관련 주제:

when은 더 동적인 Job 제어를 위해 rules와 함께 사용할 수 있습니다.
when은 파이프라인 시작 가능 시점을 제어하기 위해 workflow와 함께 사용할 수 있습니다.

`manual_confirmation`#

히스토리

GitLab 17.1에서 도입되었습니다.
GitLab 18.3에서 환경 중지 Job에 대한 지원이 도입되었습니다.

수동 Job에 대한 사용자 정의 확인 메시지를 정의하려면 when: manual과 함께 manual_confirmation을 사용합니다. when: manual이 정의된 수동 Job이 없으면 이 키워드는 효과가 없습니다.

수동 확인은 environment:action: stop을 사용하는 환경 중지 Job을 포함한 모든 수동 Job에서 작동합니다.

키워드 유형: Job 키워드. Job의 일부로만 사용할 수 있습니다.

지원되는 값:

확인 메시지 문자열.

manual_confirmation 예시:

delete_job:
  stage: post-deployment
  script:
    - make delete
  when: manual
  manual_confirmation: 'Are you sure you want to delete this environment?'

stop_production:
  stage: cleanup
  script:
    - echo "Stopping production environment"
  environment:
    name: production
    action: stop
  when: manual
  manual_confirmation: "Are you sure you want to stop the production environment?"

`start_in`#

지정된 기간 후 Job 실행을 지연하려면 start_in을 사용합니다. Job에 when: delayed를 설정해야 합니다.

키워드 유형: Job 키워드. Job의 일부로만 사용할 수 있습니다.

가능한 입력값: 초, 분 또는 시간 단위의 기간. 1주일 이하여야 합니다. 유효한 값 예시:

'5' (5초)
'10 seconds'
'30 minutes'
'1 hour'
'1 day'

start_in 예시:

deploy_production:
  stage: deploy
  script:
    - echo "Deploying to production"
  when: delayed
  start_in: 30 minutes

이 예시에서 deploy_production Job은 이전 stage가 완료된 후 30분이 지나면 시작됩니다.

추가 세부 정보:

타이머는 이전 Job이 완료될 때가 아니라 Job의 stage가 시작될 때부터 시작됩니다.
지연된 Job을 즉시 수동으로 시작하려면 파이프라인 뷰에서 Play([play])를 선택합니다.
최소 지연 기간은 1초이고 최대 지연은 1주일입니다.
start_in은 when이 delayed로 설정된 경우에만 작동합니다. when에 다른 값을 사용하면 설정이 유효하지 않습니다. Job에 rules를 사용하는 경우 start_in과 when은 Job 수준이 아닌 rules에서 정의해야 합니다. 그렇지 않으면 유효성 검사 오류가 발생합니다: config key may not be used with 'rules': start_in.
start_in은 workflow:rules에서 지원되지 않지만 구문 위반이 발생하지는 않습니다.

관련 주제:

지연 후 Job 실행

`variables`#

variables를 사용하여 CI/CD 변수를 정의합니다.

변수는 CI/CD Job에 정의하거나 최상위(전역) 키워드로 정의하여 모든 Job의 기본 CI/CD 변수로 사용할 수 있습니다.

추가 세부 정보:

YAML로 정의된 모든 변수는 연결된 Docker 서비스 컨테이너에도 설정됩니다.
YAML로 정의된 변수는 민감하지 않은 프로젝트 설정을 위한 것입니다. 민감한 정보는 보호된 변수 또는 CI/CD 시크릿에 저장합니다.
수동 파이프라인 변수와 예약된 파이프라인 변수는 기본적으로 다운스트림 파이프라인에 전달되지 않습니다. trigger:forward를 사용하여 이러한 변수를 다운스트림 파이프라인에 전달합니다.

관련 주제:

사전 정의된 변수는 러너가 자동으로 생성하여 Job에서 사용할 수 있게 하는 변수입니다.
변수를 사용하여 러너 동작을 설정할 수 있습니다.

Job `variables`#

Job의 script, before_script 또는 after_script 섹션의 명령과 일부 Job 키워드에서 Job 변수를 사용할 수 있습니다. 각 Job 키워드의 지원되는 값 섹션을 확인하여 변수를 지원하는지 확인합니다.

Job 변수는 include와 같은 전역 키워드의 값으로 사용할 수 없습니다.

지원되는 값: 변수 이름 및 값 쌍:

이름에는 숫자, 문자, 밑줄(_)만 사용할 수 있습니다. 일부 쉘에서는 첫 번째 문자가 문자여야 합니다.
값은 문자열이어야 합니다.

CI/CD 변수는 지원됩니다.

Job variables 예시:

review_job:
  variables:
    DEPLOY_SITE: "https://dev.example.com/"
    REVIEW_PATH: "/review"
  script:
    - deploy-review-script --url $DEPLOY_SITE --path $REVIEW_PATH

이 예시에서:

review_job에는 DEPLOY_SITE와 REVIEW_PATH Job 변수가 정의되어 있습니다. 두 Job 변수 모두 script 섹션에서 사용할 수 있습니다.

Default `variables`#

최상위 variables 섹션에 정의된 변수는 모든 Job의 기본 변수로 작동합니다.

각 기본 변수는 파이프라인의 모든 Job에서 사용할 수 있습니다. 단, Job에 이미 같은 이름의 변수가 정의된 경우는 예외입니다. Job에 정의된 변수가 우선하므로 Job에서 같은 이름의 기본 변수 값을 사용할 수 없습니다.

Job 변수와 마찬가지로 기본 변수는 include와 같은 다른 전역 키워드의 값으로 사용할 수 없습니다.

지원되는 값: 변수 이름 및 값 쌍:

이름에는 숫자, 문자, 밑줄(_)만 사용할 수 있습니다. 일부 쉘에서는 첫 번째 문자가 문자여야 합니다.
값은 문자열이어야 합니다.

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:
    DEPLOY_SITE: "https://dev.example.com/"
    REVIEW_PATH: "/review"
  script:
    - deploy-review-script --url $DEPLOY_SITE --path $REVIEW_PATH
  environment: production

이 예시에서:

deploy_job에는 정의된 변수가 없습니다. 기본 DEPLOY_SITE 변수가 Job에 복사되어 script 섹션에서 사용할 수 있습니다.
deploy_review_job에는 이미 DEPLOY_SITE 변수가 정의되어 있으므로 기본 DEPLOY_SITE는 Job에 복사되지 않습니다. Job에는 REVIEW_PATH Job 변수도 정의되어 있습니다. 두 Job 변수 모두 script 섹션에서 사용할 수 있습니다.

`variables:description`#

기본 변수에 대한 설명을 정의하려면 description 키워드를 사용합니다. 설명은 파이프라인을 수동으로 실행할 때 미리 채워진 변수 이름과 함께 표시됩니다.

키워드 유형: 기본 variables에서만 사용할 수 있으며, Job variables에서는 사용할 수 없습니다.

지원되는 값:

문자열. Markdown을 사용할 수 있습니다.

variables:description 예시:

variables:
  DEPLOY_NOTE:
    description: "The deployment note. Explain the reason for this deployment."

추가 세부 정보:

value 없이 사용하면 수동으로 트리거되지 않은 파이프라인에 변수가 존재하며 기본값은 빈 문자열('')입니다.

`variables:value`#

파이프라인 수준(기본) 변수의 값을 정의하려면 value 키워드를 사용합니다. variables: description과 함께 사용하면 파이프라인을 수동으로 실행할 때 변수 값이 미리 채워집니다.

키워드 유형: 기본 variables에서만 사용할 수 있으며, Job variables에서는 사용할 수 없습니다.

지원되는 값:

문자열.

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에서만 사용할 수 있으며, Job variables에서는 사용할 수 없습니다.

지원되는 값:

문자열 배열.

variables:options 예시:

variables:
  DEPLOY_ENVIRONMENT:
    value: "staging"
    options:
      - "production"
      - "staging"
      - "canary"
    description: "The deployment target. Set to 'staging' by default."

`variables:expand`#

히스토리

GitLab 15.6에서 ci_raw_variables_in_yaml_config라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화됩니다.
GitLab 15.6에서 GitLab.com에서 활성화되었습니다.
GitLab 15.7에서 GitLab Self-Managed에서 활성화되었습니다.
GitLab 15.8에서 일반 공개되었습니다. 기능 플래그 ci_raw_variables_in_yaml_config가 제거되었습니다.

expand 키워드를 사용하여 변수를 확장 가능 여부를 설정합니다.

키워드 유형: 기본 및 Job variables 모두에서 사용할 수 있습니다.

지원되는 값:

true(기본값): 변수가 확장됩니다.
false: 변수가 확장되지 않습니다.

variables:expand 예시:

variables:
  VAR1: value1
  VAR2: value2 $VAR1
  VAR3:
    value: value3 $VAR1
    expand: false

VAR2의 결과는 value2 value1입니다.
VAR3의 결과는 value3 $VAR1입니다.

추가 세부 정보:

expand 키워드는 기본 및 Job variables 키워드에서만 사용할 수 있습니다. rules:variables 또는 workflow:rules:variables에서는 사용할 수 없습니다.

GitLab 템플릿 컬렉션에서 가져온 파일

Tier: Premium, Ultimate
Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated

원문 보기

번역일: 2026-05-22

요약

이 문서는 GitLab .gitlab-ci.yml 파일의 설정 옵션 목록입니다. 이 파일에서 파이프라인을 구성하는 CI/CD job을 정의합니다.

이미 기본 CI/CD 개념에 익숙한 경우, 간단한 또는 복잡한 파이프라인을 보여주는 튜토리얼에 따라 직접 .gitlab-ci.yml 파일을 작성해 보세요.
예시 모음은 GitLab CI/CD 예시를 참조하세요.
엔터프라이즈에서 사용되는 대규모 .gitlab-ci.yml 파일을 보려면 gitlab의 .gitlab-ci.yml 파일을 참조하세요.

.gitlab-ci.yml 파일을 편집할 때는 CI Lint 도구로 유효성을 검사할 수 있습니다.

GitLab CI/CD 설정은 YAML 형식을 사용하므로, 별도로 명시되지 않는 한 키워드 순서는 중요하지 않습니다.

보다 동적인 파이프라인 설정 옵션은 CI/CD 표현식을 사용하세요.

키워드#

GitLab CI/CD 파이프라인 설정에는 다음이 포함됩니다:

파이프라인 동작을 설정하는 전역 키워드:

키워드	설명
`default`	job 키워드의 사용자 정의 기본값.
`include`	다른 YAML 파일에서 설정을 가져옵니다.
`stages`	파이프라인 Stage의 이름과 순서.
`variables`	파이프라인의 모든 job에 대한 기본 CI/CD 변수를 정의합니다.
`workflow`	어떤 유형의 파이프라인이 실행될지 제어합니다.

헤더 키워드

키워드 설명

spec 외부 설정 파일의 사양을 정의합니다.

키워드	설명
`spec`	외부 설정 파일의 사양을 정의합니다.

job 키워드로 설정된 Jobs:

키워드	설명
`after_script`	job 후 실행되는 명령어 세트를 재정의합니다.
`allow_failure`	job이 실패해도 됩니다. 실패한 job은 파이프라인을 실패시키지 않습니다.
`artifacts`	job 성공 시 job에 첨부할 파일 및 디렉토리 목록.
`before_script`	job 전 실행되는 명령어 세트를 재정의합니다.
`cache`	이후 실행 간에 캐시해야 할 파일 목록.
`coverage`	특정 job에 대한 코드 커버리지 설정.
`dast_configuration`	job 수준에서 DAST 프로필의 설정을 사용합니다.
`dependencies`	아티팩트를 가져올 job 목록을 제공하여 특정 job에 전달되는 아티팩트를 제한합니다.
`environment`	job이 배포하는 환경의 이름.
`extends`	이 job이 상속받는 설정 항목.
`identity`	페더레이션 ID를 사용하여 서드파티 서비스로 인증합니다.
`image`	Docker 이미지를 사용합니다.
`inherit`	모든 job이 상속받을 전역 기본값을 선택합니다.
`interruptible`	새 실행으로 인해 불필요해진 경우 job을 취소할 수 있는지 정의합니다.
`manual_confirmation`	수동 job에 대한 사용자 정의 확인 메시지를 정의합니다.
`needs`	Stage 순서보다 이른 시점에 job을 실행합니다.
`pages`	GitLab Pages와 함께 사용하기 위해 job 결과물을 업로드합니다.
`parallel`	병렬로 실행할 job 인스턴스 수.
`release`	러너가 릴리스 객체를 생성하도록 지시합니다.
`resource_group`	job 동시성을 제한합니다.
`retry`	실패 시 job이 자동으로 재시도할 시기와 횟수.
`rules`	job의 선택된 속성과 job 생성 여부를 평가하고 결정하는 조건 목록.
`script`	러너가 실행하는 셸 스크립트.
`run`	러너가 실행하는 run 설정.
`secrets`	job에 필요한 CI/CD 시크릿.
`services`	Docker 서비스 이미지를 사용합니다.
`stage`	job stage를 정의합니다.
`start_in`	지정된 기간 동안 job 실행을 지연합니다. `when: delayed`가 필요합니다.
`tags`	러너를 선택하는 데 사용되는 태그 목록.
`timeout`	프로젝트 전체 설정보다 우선하는 사용자 정의 job 수준 타임아웃을 정의합니다.
`trigger`	다운스트림 파이프라인 트리거를 정의합니다.
`variables`	개별 job에 대한 CI/CD 변수를 정의합니다.
`when`	job 실행 시기.

더 이상 사용을 권장하지 않는 더 이상 사용되지 않는 키워드.

전역 키워드#

일부 키워드는 job에 정의되지 않습니다. 이러한 키워드는 파이프라인 동작을 제어하거나 추가 파이프라인 설정을 가져옵니다.

`default`#

히스토리

id_tokens 지원이 GitLab 16.4에서 도입되었습니다.

일부 키워드에 대한 전역 기본값을 설정할 수 있습니다. 각 기본 키워드는 해당 키워드가 이미 정의되지 않은 모든 job에 복사됩니다.

기본 설정은 job 설정과 병합되지 않습니다. job에 이미 키워드가 정의된 경우, job 키워드가 우선하며 해당 키워드의 기본 설정은 사용되지 않습니다.

키워드 유형: 전역 키워드.

지원되는 값: 이러한 키워드는 사용자 정의 기본값을 가질 수 있습니다:

after_script
artifacts
before_script
cache
hooks
id_tokens
image
interruptible
retry
services
tags 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는 파이프라인의 모든 job에 대한 기본 키워드입니다.
rspec job에는 image 또는 retry가 정의되어 있지 않으므로, image: ruby:3.0과 retry: 2의 기본값을 사용합니다.
rspec 2.7 job에는 retry가 정의되어 있지 않지만, image가 명시적으로 정의되어 있습니다. 기본 retry: 2를 사용하지만, 기본 image는 무시하고 job에 정의된 image: ruby:2.7을 사용합니다.

추가 세부 정보:

inherit:default로 job의 기본 키워드 상속을 제어합니다.
전역 기본값은 다운스트림 파이프라인을 트리거한 업스트림 파이프라인과 독립적으로 실행되는 다운스트림 파이프라인에 전달되지 않습니다.

`include`#

템플릿 파일을 중앙 리포지터리에 저장하고 프로젝트에 포함시킬 수도 있습니다.

include 파일은:

.gitlab-ci.yml 파일의 내용과 병합됩니다.
include 키워드의 위치에 관계없이 항상 먼저 평가되고 .gitlab-ci.yml 파일의 내용과 병합됩니다.

모든 파일을 해석하는 시간 제한은 30초입니다.

키워드 유형: 전역 키워드.

지원되는 값: include 서브키:

include:component
include:local
include:project
include:remote
include:template

그리고 선택적으로:

include:inputs
include:rules
include:integrity
include:cache

추가 세부 정보:

include 키워드와 함께 사용할 수 있는 특정 CI/CD 변수만 사용 가능합니다.
병합을 사용하여 로컬에서 포함된 CI/CD 설정을 사용자 정의하고 재정의합니다.
.gitlab-ci.yml 파일에 동일한 job 이름이나 전역 키워드가 있으면 포함된 설정을 재정의할 수 있습니다. 두 설정이 병합되며, .gitlab-ci.yml 파일의 설정이 포함된 설정보다 우선합니다.
다음을 재실행하는 경우:
- Job의 경우: include 파일이 다시 가져와지지 않습니다. 파이프라인의 모든 job은 파이프라인 생성 시 가져온 설정을 사용합니다. 소스 include 파일에 대한 변경 사항은 job 재실행에 영향을 미치지 않습니다.
- 파이프라인의 경우: include 파일이 다시 가져와집니다. 마지막 파이프라인 실행 이후 변경된 경우, 새 파이프라인은 변경된 설정을 사용합니다.
중첩된 것을 포함하여 기본적으로 파이프라인당 최대 150개의 include를 가질 수 있습니다. 추가로:
- GitLab 16.0 이상에서 GitLab Self-Managed 사용자는 최대 include 값을 변경할 수 있습니다.
- GitLab 15.10 이상에서 최대 150개의 include를 가질 수 있습니다. 중첩 include에서는 동일한 파일을 여러 번 포함할 수 있지만, 중복 include는 한도에 포함됩니다.
- GitLab 14.9부터 GitLab 15.9까지 최대 100개의 include를 가질 수 있습니다. 동일한 파일을 중첩 include에 여러 번 포함할 수 있지만, 중복은 무시됩니다.

`include:component`#

include:component를 사용하여 파이프라인 설정에 CI/CD 컴포넌트를 추가합니다.

키워드 유형: 전역 키워드.

지원되는 값: <fully-qualified-domain-name>/<project-path>/<component-name>@<specific-version> 형식으로 된 CI/CD 컴포넌트의 전체 주소.

include:component 예시:

include:
  - component: $CI_SERVER_FQDN/my-org/security-components/secret-detection@1.0

관련 항목:

CI/CD 컴포넌트 사용.

`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 키워드가 포함된 파일의 위치를 기준으로 항상 평가됩니다. 다른 프로젝트의 설정 파일에 중첩 include가 있는 경우, include: local은 해당 다른 프로젝트에서 파일을 확인합니다.

`include:project`#

동일한 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 키워드가 포함된 파일의 위치를 기준으로 항상 평가됩니다. 다른 프로젝트의 설정 파일에 중첩 include가 있는 경우, include: local은 해당 다른 프로젝트에서 파일을 확인합니다.
파이프라인이 시작되면, 모든 방법으로 포함된 .gitlab-ci.yml 파일 설정이 평가됩니다. 설정은 시점의 스냅샷이며 데이터베이스에 저장됩니다. GitLab은 다음 파이프라인이 시작될 때까지 참조된 .gitlab-ci.yml 파일 설정에 대한 변경 사항을 반영하지 않습니다.
다른 비공개 프로젝트에서 YAML 파일을 포함하는 경우, 파이프라인을 실행하는 사용자가 두 프로젝트 모두의 멤버여야 하며 파이프라인 실행에 적절한 권한을 가져야 합니다. 사용자가 포함된 파일 중 하나에 접근 권한이 없는 경우 not found or access denied 오류가 표시될 수 있습니다.
다른 프로젝트의 CI/CD 설정 파일을 포함할 때 주의하세요. CI/CD 설정 파일이 변경될 때 파이프라인이나 알림이 트리거되지 않습니다. 보안 관점에서 이는 서드파티 종속성을 가져오는 것과 유사합니다. ref를 위해 다음을 고려하세요:
- 가장 안정적인 옵션인 특정 SHA 해시를 사용합니다. 짧은 SHA 해시가 ref에 대해 모호할 수 있으므로 원하는 커밋이 참조되도록 40자 전체 SHA 해시를 사용합니다.
- 다른 프로젝트의 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는 공개 사용자로서 컨텍스트 없이 실행되므로, 공개 프로젝트나 템플릿만 포함할 수 있습니다. 중첩 include의 include 섹션에서는 변수를 사용할 수 없습니다.
다른 프로젝트의 CI/CD 설정 파일을 포함할 때 주의하세요. 다른 프로젝트의 파일이 변경될 때 파이프라인이나 알림이 트리거되지 않습니다. 보안 관점에서 이는 서드파티 종속성을 가져오는 것과 유사합니다. 포함된 파일의 무결성을 확인하려면 integrity 키워드 사용을 고려하세요. 소유한 다른 GitLab 프로젝트로 링크하는 경우, 변경 관리 규칙을 적용하기 위해 보호된 브랜치와 보호된 태그 사용을 모두 고려하세요.

`include:template`#

include:template을 사용하여 .gitlab-ci.yml 템플릿을 포함합니다.

키워드 유형: 전역 키워드.

지원되는 값:

CI/CD 템플릿의 파일 이름, 예를 들어 Auto-DevOps.gitlab-ci.yml. 모든 템플릿이 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의 include 섹션에서는 변수를 사용할 수 없습니다.

`include:inputs`#

히스토리

GitLab 15.11에서 베타 기능으로 도입되었습니다.
GitLab 17.0에서 일반 제공되었습니다.

포함된 설정이 spec:inputs를 사용하고 파이프라인에 추가되는 경우, include: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를 사용할 때 입력값 설정.

`include:rules`#

rules와 include를 함께 사용하여 다른 설정 파일을 조건부로 포함할 수 있습니다.

키워드 유형: 전역 키워드.

지원되는 값: 이 rules 서브키:

rules:if.
rules:exists.
rules:changes.

일부 CI/CD 변수가 지원됩니다.

include:rules 예시:

include:
  - local: build_jobs.yml
    rules:
      - if: $INCLUDE_BUILDS == "true"

test-job:
  stage: test
  script: echo "This is a test job"

이 예시에서 INCLUDE_BUILDS 변수가:

true인 경우: build_jobs.yml 설정이 파이프라인에 포함됩니다.
true가 아니거나 존재하지 않는 경우: build_jobs.yml 설정이 파이프라인에 포함되지 않습니다.

관련 항목:

include와 함께 사용하는 예시:
- rules:if.
- rules:changes.
- rules:exists.

`include:integrity`#

히스토리

GitLab 17.9에서 도입되었습니다.

키워드 유형: 전역 키워드.

지원되는 값: 포함된 내용의 Base64 인코딩된 SHA256 해시.

include:integrity 예시:

include:
  - remote: 'https://gitlab.com/example-project/-/raw/main/.gitlab-ci.yml'
    integrity: 'sha256-L3/GAoKaw0Arw6hDCKeKQlV1QPEgHYxGBHsH4zG1IY8='

`include:cache`#

히스토리

GitLab 18.9에서 ci_cache_remote_includes라는 기능 플래그와 함께
GitLab 19.0에서 일반 공개. 기능 플래그 ci_cache_remote_includes 제거됨.

cache가 정의되지 않으면, 매번 원격 파일이 가져와집니다.

키워드 유형: 전역 키워드.

지원되는 값:

true: 기본 TTL 1시간으로 캐싱을 활성화합니다.
기간(문자열): minutes, hours, 또는 days와 같은 시간 단위를 사용하는 유효한 TTL 기간 문자열(최소 1 minute).

include:cache 예시:

include:
  - remote: 'https://gitlab.com/example-project/-/raw/main/sample1.gitlab-ci.yml'
    cache: true
  - remote: 'https://gitlab.com/example-project/-/raw/main/sample2.gitlab-ci.yml'
    cache: '1 day'

추가 세부 정보:

캐싱은 include:remote에서만 사용 가능합니다.
원격 파일이 캐시된 후, 원격 파일 내용이 변경되더라도 TTL이 만료될 때까지 캐시된 버전이 계속 사용됩니다.
cache와 함께 integrity를 사용하면, 캐시된 내용을 사용할 때도 모든 파이프라인 실행에서 무결성 검사가 수행됩니다.

`stages`#

히스토리

중첩된 문자열 배열 지원이 GitLab 16.9에서 도입되었습니다.

stages를 사용하여 job 그룹을 포함하는 Stage를 정의합니다. job에서 stage를 사용하여 특정 Stage에서 실행되도록 job을 설정합니다.

.gitlab-ci.yml 파일에 stages가 정의되지 않으면, 기본 파이프라인 Stage는 다음과 같습니다:

.pre
build
test
deploy
.post

stages의 항목 순서가 job의 실행 순서를 정의합니다:

동일한 Stage의 job은 병렬로 실행됩니다.
다음 Stage의 job은 이전 Stage의 job이 성공적으로 완료된 후 실행됩니다.

파이프라인에 .pre 또는 .post Stage의 job만 있으면 실행되지 않습니다. 다른 Stage에 최소 하나의 다른 job이 있어야 합니다.

키워드 유형: 전역 키워드.

stages 예시:

stages:
  - build
  - test
  - deploy

이 예시에서:

build의 모든 job이 병렬로 실행됩니다.
build의 모든 job이 성공하면, test job이 병렬로 실행됩니다.
test의 모든 job이 성공하면, deploy job이 병렬로 실행됩니다.
deploy의 모든 job이 성공하면, 파이프라인이 passed로 표시됩니다.

어떤 job이 실패하면, 파이프라인이 failed로 표시되고 이후 Stage의 job은 시작되지 않습니다. 현재 Stage의 job은 중지되지 않고 계속 실행됩니다.

추가 세부 정보:

job이 stage를 지정하지 않으면, job이 test Stage에 할당됩니다.
Stage가 정의되었지만 job이 사용하지 않으면, 파이프라인에서 Stage가 표시되지 않으며, 이는 컴플라이언스 파이프라인 설정에 도움이 될 수 있습니다:
- Stage는 컴플라이언스 설정에서 정의할 수 있지만 사용되지 않으면 숨겨집니다.
- 개발자가 job 정의에 사용하면 정의된 Stage가 표시됩니다.

관련 항목:

Stage 순서를 무시하고 job을 더 일찍 시작하려면 needs 키워드를 사용합니다.

`workflow`#

workflow를 사용하여 파이프라인 동작을 제어합니다.

workflow 설정에서 일부 사전 정의된 CI/CD 변수를 사용할 수 있지만, job이 시작될 때만 정의되는 변수는 사용할 수 없습니다.

관련 항목:

`workflow:auto_cancel:on_new_commit`#

히스토리

GitLab 16.8에서 ci_workflow_auto_cancel_on_new_commit이라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화됩니다.
GitLab 16.9에서 GitLab.com 및 GitLab Self-Managed에서 활성화되었습니다.
GitLab 16.10에서 일반 제공되었습니다. 기능 플래그 ci_workflow_auto_cancel_on_new_commit이 제거되었습니다.

workflow:auto_cancel:on_new_commit을 사용하여 중복 파이프라인 자동 취소 기능의 동작을 설정합니다.

지원되는 값:

conservative: 파이프라인을 취소하되, interruptible: false인 job이 아직 시작되지 않은 경우에만 취소합니다. 정의되지 않은 경우 기본값입니다.
interruptible: interruptible: true인 job만 취소합니다.
none: job을 자동으로 취소하지 않습니다.

workflow:auto_cancel:on_new_commit 예시:

workflow:
  auto_cancel:
    on_new_commit: interruptible

job1:
  interruptible: true
  script: sleep 60

job2:
  interruptible: false  # Default when not defined.
  script: sleep 60

이 예시에서:

새 커밋이 브랜치에 푸시되면, GitLab이 새 파이프라인을 생성하고 job1과 job2가 시작됩니다.
job이 완료되기 전에 새 커밋이 브랜치에 푸시되면, job1만 취소됩니다.

`workflow:auto_cancel:on_job_failure`#

히스토리

GitLab 16.10에서 auto_cancel_pipeline_on_job_failure이라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화됩니다.
GitLab 16.11에서 일반 제공되었습니다. 기능 플래그 auto_cancel_pipeline_on_job_failure이 제거되었습니다.

하나의 job이 실패하는 즉시 취소해야 할 job을 설정하려면 workflow:auto_cancel:on_job_failure를 사용합니다.

지원되는 값:

all: 하나의 job이 실패하는 즉시 파이프라인과 모든 실행 중인 job을 취소합니다.
none: 어떤 job도 자동으로 취소하지 않습니다.

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은 시작되지 않습니다.

관련 항목:

다운스트림 파이프라인에서 상위 파이프라인 자동 취소

`workflow:name`#

히스토리

GitLab 15.5에서 pipeline_name이라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화됩니다.
GitLab 15.7에서 GitLab.com 및 GitLab Self-Managed에서 활성화되었습니다.
GitLab 15.8에서 일반 제공되었습니다. 기능 플래그 pipeline_name이 제거되었습니다.

workflow:에서 name을 사용하여 파이프라인 이름을 정의할 수 있습니다.

모든 파이프라인에 정의된 이름이 할당됩니다. 이름의 앞뒤 공백은 제거됩니다.

지원되는 값:

문자열.
CI/CD 변수.
두 가지의 조합.

workflow:name 예시:

사전 정의된 변수를 사용한 간단한 파이프라인 이름:

workflow:
  name: 'Pipeline for branch: $CI_COMMIT_BRANCH'

파이프라인 조건에 따라 서로 다른 파이프라인 이름을 갖는 설정:

variables:
  PROJECT1_PIPELINE_NAME: 'Default pipeline name'  # A default is not required

workflow:
  name: '$PROJECT1_PIPELINE_NAME'
  rules:
    - if: '$CI_MERGE_REQUEST_LABELS =~ /pipeline:run-in-ruby3/'
      variables:
        PROJECT1_PIPELINE_NAME: 'Ruby 3 pipeline'
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      variables:
        PROJECT1_PIPELINE_NAME: 'MR pipeline: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME'
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH  # For default branch pipelines, use the default name

추가 세부 정보:

이름이 빈 문자열이면, 파이프라인에 이름이 할당되지 않습니다. CI/CD 변수만으로 구성된 이름은 모든 변수도 비어 있는 경우 빈 문자열로 평가될 수 있습니다.
workflow:rules:variables는 모든 job에서 사용할 수 있는 기본 변수가 됩니다. 기본적으로 변수를 다운스트림 파이프라인으로 전달하는 trigger job도 포함됩니다. 다운스트림 파이프라인이 동일한 변수를 사용하는 경우, 변수가 업스트림 변수 값으로 덮어씌워집니다. 다음 중 하나를 수행해야 합니다:
- PROJECT1_PIPELINE_NAME과 같이 모든 프로젝트의 파이프라인 설정에서 고유한 변수 이름을 사용합니다.
- trigger job에서 inherit:variables를 사용하고 다운스트림 파이프라인에 전달하려는 정확한 변수를 나열합니다.

`workflow:rules`#

workflow의 rules 키워드는 job에 정의된 rules와 유사하지만, 전체 파이프라인이 생성될지 여부를 제어합니다.

어떤 규칙도 true로 평가되지 않으면, 파이프라인이 실행되지 않습니다.

지원되는 값: job 수준 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로 끝나지 않고 파이프라인이 다음 중 하나인 경우 파이프라인이 실행됩니다:

머지 리퀘스트
기본 브랜치.

추가 세부 정보:

규칙이 브랜치 파이프라인(기본 브랜치 제외)과 머지 리퀘스트 파이프라인 모두에 일치하면, 중복 파이프라인이 발생할 수 있습니다.
start_in, allow_failure, needs는 workflow:rules에서 지원되지 않지만, 문법 위반을 유발하지 않습니다. 효과가 없더라도 workflow:rules에서 사용하지 마세요. 향후 문법 오류를 유발할 수 있습니다. 자세한 내용은 이슈 436473을 참조하세요.

관련 항목:

`workflow:rules:variables`#

workflow:rules에서 variables를 사용하여 특정 파이프라인 조건에 대한 변수를 정의할 수 있습니다.

키워드 유형: 전역 키워드.

지원되는 값: 변수 이름과 값 쌍:

이름은 숫자, 문자, 밑줄(_)만 사용할 수 있습니다.
값은 문자열이어야 합니다.

workflow:rules:variables 예시:

variables:
  DEPLOY_VARIABLE: "default-deploy"

workflow:
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      variables:
        DEPLOY_VARIABLE: "deploy-production"  # Override globally-defined DEPLOY_VARIABLE
    - if: $CI_COMMIT_BRANCH =~ /feature/
      variables:
        IS_A_FEATURE: "true"                  # Define a new variable.
    - if: $CI_COMMIT_BRANCH                   # Run the pipeline in other cases

job1:
  variables:
    DEPLOY_VARIABLE: "job1-default-deploy"
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      variables:                                   # Override DEPLOY_VARIABLE defined
        DEPLOY_VARIABLE: "job1-deploy-production"  # at the job level.
    - when: on_success                             # Run the job in other cases
  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는 모든 job에서 사용할 수 있는 기본 변수가 됩니다. 기본적으로 변수를 다운스트림 파이프라인으로 전달하는 trigger job도 포함됩니다. 다운스트림 파이프라인이 동일한 변수를 사용하는 경우, 변수가 업스트림 변수 값으로 덮어씌워집니다. 다음 중 하나를 수행해야 합니다:
- PROJECT1_VARIABLE_NAME과 같이 모든 프로젝트의 파이프라인 설정에서 고유한 변수 이름을 사용합니다.
- trigger job에서 inherit:variables를 사용하고 다운스트림 파이프라인에 전달하려는 정확한 변수를 나열합니다.

`workflow:rules:auto_cancel`#

히스토리

GitLab 16.8에서 ci_workflow_auto_cancel_on_new_commit이라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화됩니다.
GitLab 16.9에서 GitLab.com 및 GitLab Self-Managed에서 활성화되었습니다.
GitLab 16.10에서 일반 제공되었습니다. 기능 플래그 ci_workflow_auto_cancel_on_new_commit이 제거되었습니다.
workflow:rules의 on_job_failure 옵션이 GitLab 16.10에서 auto_cancel_pipeline_on_job_failure이라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화됩니다.
workflow:rules의 on_job_failure 옵션이 GitLab 16.11에서 일반 제공되었습니다. 기능 플래그 auto_cancel_pipeline_on_job_failure이 제거되었습니다.

workflow:rules:auto_cancel을 사용하여 workflow:auto_cancel:on_new_commit 또는 workflow:auto_cancel:on_job_failure 기능의 동작을 설정합니다.

지원되는 값:

on_new_commit: workflow:auto_cancel:on_new_commit
on_job_failure: workflow:auto_cancel:on_job_failure

workflow:rules:auto_cancel 예시:

workflow:
  auto_cancel:
    on_new_commit: interruptible
    on_job_failure: all
  rules:
    - if: $CI_COMMIT_REF_PROTECTED == 'true'
      auto_cancel:
        on_new_commit: none
        on_job_failure: none
    - when: always                  # Run the pipeline in other cases

test-job1:
  script: sleep 10
  interruptible: false

test-job2:
  script: sleep 10
  interruptible: true

보호되지 않은 브랜치에서 새 커밋이 푸시되면, test-job1은 계속 실행되고 test-job2는 취소됩니다.
보호된 브랜치에서 새 커밋이 푸시되면, test-job1과 test-job2 모두 계속 실행됩니다.

헤더 키워드#

일부 키워드는 YAML 설정 파일의 헤더 섹션에 정의해야 합니다. 헤더는 파일 맨 위에 있어야 하며, ---로 나머지 설정과 구분됩니다.

`spec`#

히스토리

GitLab 15.11에서 베타 기능으로 도입되었습니다.

include 키워드로 파이프라인에 설정이 추가될 때 파이프라인의 동작을 설정하려면 YAML 파일 헤더에 spec 섹션을 추가합니다.

Spec은 설정 파일 상단에 ---로 나머지 설정과 구분되는 헤더 섹션에 선언해야 합니다.

`spec:inputs`#

spec:inputs를 사용하여 CI/CD 설정의 입력값을 정의합니다.

키워드 유형: 헤더 키워드. spec은 설정 파일 상단의 헤더 섹션에 선언해야 합니다.

지원되는 값: 예상 입력값을 나타내는 문자열 해시.

spec:inputs 예시:

spec:
  inputs:
    environment:
    job-stage:
---

scan-website:
  stage: $[[ inputs.job-stage ]]
  script: ./scan-website $[[ inputs.environment ]]

추가 세부 정보:

spec:inputs:default를 사용하여 기본값을 설정하지 않는 한 입력값은 필수입니다. include:inputs와 함께 입력값만 사용하지 않는 한 필수 입력값은 피하세요.
spec:inputs:type를 사용하여 다른 입력값 유형을 설정하지 않는 한 입력값은 문자열을 예상합니다.
보간 블록이 포함된 문자열은 1MB를 초과할 수 없습니다.
보간 블록 내의 문자열은 1KB를 초과할 수 없습니다.
새 파이프라인을 실행할 때 입력값을 정의할 수 있습니다.

관련 항목:

spec:inputs로 입력 파라미터 정의.

`spec:inputs:default`#

히스토리

GitLab 15.11에서 베타 기능으로 도입되었습니다.

spec:inputs:default로 기본값을 설정하지 않는 한 포함될 때 입력값은 필수입니다.

기본값이 없도록 하려면 default: ''를 사용합니다.

키워드 유형: 헤더 키워드. spec은 설정 파일 상단의 헤더 섹션에 선언해야 합니다.

지원되는 값: 기본값을 나타내는 문자열, 또는 ''.

spec:inputs:default 예시:

spec:
  inputs:
    website:
    user:
      default: 'test-user'
    flags:
      default: ''
---
# The pipeline configuration would follow...

이 예시에서:

website는 필수이며 정의해야 합니다.
user는 선택적입니다. 정의되지 않으면 값이 test-user입니다.
flags는 선택적입니다. 정의되지 않으면 값이 없습니다.

추가 세부 정보:

다음 경우에 파이프라인이 유효성 검사 오류로 실패합니다:
- default와 options를 함께 사용하지만, 기본값이 나열된 옵션 중 하나가 아닌 경우.
- default와 regex를 함께 사용하지만, 기본값이 정규식과 일치하지 않는 경우.
- 값이 type과 일치하지 않는 경우.

`spec:inputs:description`#

히스토리

GitLab 16.5에서 도입되었습니다.

키워드 유형: 헤더 키워드. spec은 설정 파일 상단의 헤더 섹션에 선언해야 합니다.

지원되는 값: 설명을 나타내는 문자열.

spec:inputs:description 예시:

spec:
  inputs:
    flags:
      description: 'Sample description of the `flags` input details.'
---
# The pipeline configuration would follow...

`spec:inputs:options`#

히스토리

GitLab 16.6에서 도입되었습니다.

입력값에 대한 허용 값 목록을 지정하려면 options를 사용합니다. 입력당 최대 50개의 옵션이 있습니다.

키워드 유형: 헤더 키워드. spec은 설정 파일 상단의 헤더 섹션에 선언해야 합니다.

지원되는 값: 입력 옵션의 배열. string과 number type 입력값만 옵션과 함께 사용할 수 있습니다.

spec:inputs:options 예시:

spec:
  inputs:
    environment:
      options:
        - development
        - staging
        - production
---
# The pipeline configuration would follow...

이 예시에서:

environment는 필수이며 목록의 값 중 하나로 정의해야 합니다.

추가 세부 정보:

다음 경우에 파이프라인이 유효성 검사 오류로 실패합니다:
- 입력값이 options와 default를 함께 사용하지만, 기본값이 나열된 옵션 중 하나가 아닌 경우.
- 입력 옵션이 type과 일치하지 않는 경우. options를 사용할 때는 boolean이 아닌 string 또는 number만 가능합니다.

`spec:inputs:regex`#

히스토리

GitLab 16.5에서 도입되었습니다.

입력값이 일치해야 하는 정규 표현식을 지정하려면 spec:inputs:regex를 사용합니다.

키워드 유형: 헤더 키워드. spec은 설정 파일 상단의 헤더 섹션에 선언해야 합니다.

지원되는 값: 정규 표현식이어야 합니다.

spec:inputs:regex 예시:

spec:
  inputs:
    version:
      regex: ^v\d\.\d+(\.\d+)?$
---
# The pipeline configuration would follow...

추가 세부 정보:

inputs:regex는 number 또는 boolean이 아닌 string type에서만 사용할 수 있습니다.
정규 표현식을 / 문자로 감싸지 마세요. 예를 들어, /regex.*/ 대신 regex.*를 사용합니다.
inputs:regex는 RE2를 사용하여 정규 표현식을 파싱합니다.
정규 표현식에 대한 입력값 유효성 검사는 변수 확장 전에 수행됩니다. 입력 텍스트에 변수 이름이 포함된 경우, 변수 값이 아닌 입력의 원시 값(변수 이름)이 유효성 검사됩니다.

`spec:inputs:rules`#

히스토리

GitLab 18.7에서 도입되었습니다.

다른 입력값의 값에 기반하여 입력값에 대한 조건부 options와 default 값을 정의하려면 spec:inputs:rules를 사용합니다.

키워드 유형: 헤더 키워드. spec은 설정 파일 상단의 헤더 섹션에 선언해야 합니다.

지원되는 값: 규칙 객체의 배열. 각 규칙은 다음을 가질 수 있습니다:

if: $[[ inputs.input-id ]] 문법을 사용하여 입력값을 확인하는 조건부 표현식.
options: 입력값에 허용되는 값의 배열.
default: 이 규칙이 일치할 때 입력값의 기본값. 사용자가 입력값에 자신의 값을 입력할 수 있도록 허용하려면 default: null을 사용합니다.

spec:inputs:rules 예시:

spec:
  inputs:
    environment:
      options: ['development', 'production']
      default: 'development'

    instance_type:
      description: 'VM instance size'
      rules:
        - if: $[[ inputs.environment ]] == 'development'
          options: ['small', 'medium']
          default: 'small'
        - if: $[[ inputs.environment ]] == 'production'
          options: ['large', 'xlarge']
          default: 'large'
---

deploy:
  script: echo "Deploying $[[ inputs.instance_type ]] instance"

추가 세부 정보:

규칙은 순서대로 평가됩니다. 일치하는 if 조건이 있는 첫 번째 규칙이 사용됩니다.
if 조건이 없는 규칙은 다른 규칙이 일치하지 않을 때 대체 규칙으로 작동합니다.
대체 규칙은 최소 하나의 값으로 options를 정의해야 합니다.
options가 있는 모든 규칙은 options 목록에 있는 default 값을 정의해야 합니다.
동일한 입력값에 rules와 최상위 options 또는 default를 함께 사용할 수 없습니다.

관련 항목:

spec:inputs:rules로 조건부 입력 옵션 정의.

`spec:inputs:type`#

기본적으로 입력값은 문자열을 예상합니다. spec:inputs:type을 사용하여 입력값에 필요한 다른 유형을 설정합니다.

키워드 유형: 헤더 키워드. spec은 설정 파일 상단의 헤더 섹션에 선언해야 합니다.

지원되는 값: 다음 중 하나:

array: 입력값의 배열을 허용합니다.
string: 문자열 입력값을 허용합니다(정의되지 않은 경우 기본값).
number: 숫자 입력값만 허용합니다.
boolean: true 또는 false 입력값만 허용합니다.

spec:inputs:type 예시:

spec:
  inputs:
    job_name:
    website:
      type: string
    port:
      type: number
    available:
      type: boolean
    array_input:
      type: array
---
# The pipeline configuration would follow...

`spec:include`#

히스토리

GitLab 18.6에서 ci_file_inputs이라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화됩니다.
GitLab 18.9에서 일반 제공되었습니다. 기능 플래그 ci_file_inputs이 제거되었습니다.

spec:include를 사용하여 다른 파일에서 외부 입력 정의를 포함합니다. 여러 파이프라인 설정에서 입력 정의를 공유하고 재사용할 수 있습니다.

키워드 유형: 헤더 키워드. spec은 설정 파일 상단의 헤더 섹션에 선언해야 합니다.

지원되는 값: 포함 위치의 배열. local, remote, project include만 지원합니다.

spec:include 예시:

spec:
  include:
    - local: /shared-inputs.yml
  inputs:
    environment:
      default: production
---

deploy:
  script: echo "Deploying to $[[ inputs.environment ]]"

다른 소스의 여러 include:

spec:
  include:
    - local: /base-inputs.yml
    - remote: 'https://example.com/ci/common-inputs.yml'
    - project: 'my-group/shared-configs'
      ref: main
      file: '/ci/team-inputs.yml'
  inputs:
    environment:
      default: production
---

deploy:
  script: echo "Deploying to $[[ inputs.environment ]]"

추가 세부 정보:

CI/CD 컴포넌트에서 spec:include를 사용할 수 없습니다.
외부 입력 파일은 inputs 키만 포함해야 합니다. 다른 키는 유효성 검사 오류를 유발합니다.
외부 입력이 먼저 병합되고, 그 다음 인라인 입력이 적용됩니다.
인라인 입력은 포함된 입력과 동일한 이름을 가질 수 없습니다.
여러 입력 파일을 포함하면, 지정된 순서대로 병합됩니다.
local, remote, project include 유형을 지원합니다. template, component, 또는 artifact include는 지원하지 않습니다.

관련 항목:

외부 파일에서 입력값 사용.

`spec:component`#

히스토리

GitLab 18.6에서 ci_component_context_interpolation이라는 플래그와 함께 베타로 도입되었습니다. 기본적으로 활성화됩니다.
GitLab 18.7에서 일반 제공되었습니다. 기능 플래그 ci_component_context_interpolation이 제거되었습니다.

CI/CD 컴포넌트의 보간에 사용 가능한 컴포넌트 컨텍스트 데이터를 정의하려면 spec:component를 사용합니다.

컴포넌트 템플릿에서 컴포넌트 컨텍스트 값을 참조하려면 보간 형식 $[[ component.field-name ]]을 사용합니다.

키워드 유형: 헤더 키워드. spec은 설정 파일 상단의 헤더 섹션에 선언해야 합니다.

지원되는 값: 문자열 배열. 각 문자열은 다음 중 하나여야 합니다:

name: 컴포넌트 경로에 지정된 컴포넌트 이름.
sha: 컴포넌트의 커밋 SHA.
version: 카탈로그 리소스의 확인된 시맨틱 버전. 다음의 경우 null을 반환합니다:
- 컴포넌트가 카탈로그 리소스가 아닌 경우.
- 참조가 브랜치 이름이나 커밋 SHA인 경우(릴리스 버전이 아닌 경우).
reference: 컴포넌트 경로에서 @ 뒤에 지정된 원래 참조. 예를 들어, 1.0, ~latest, 브랜치 이름, 또는 커밋 SHA.

spec:component 예시:

spec:
  component: [name, version, reference]
  inputs:
    stage:
      default: build
---

build-image:
  stage: $[[ inputs.stage ]]
  image: registry.example.com/$[[ component.name ]]:$[[ component.version ]]
  script:
    - echo "Building with component version $[[ component.version ]]"
    - echo "Component reference: $[[ component.reference ]]"

추가 세부 정보:

version 필드는 다음을 사용할 때 실제 시맨틱 버전으로 확인됩니다:
- @1.0.0과 같은 전체 버전(returns 1.0.0)
- @1.0과 같은 부분 버전(최신 일치 버전 반환, 예: 1.0.2)
- @~latest(최신 버전 반환)
reference 필드는 항상 @ 뒤에 지정된 정확한 값을 반환합니다:
- @1.0은 1.0을 반환합니다(version은 1.0.2를 반환할 수 있습니다)
- @~latest는 ~latest를 반환합니다(version은 실제 버전 번호를 반환합니다)
- @abc123은 abc123을 반환합니다(version은 null을 반환합니다)

관련 항목:

컴포넌트에서 컴포넌트 컨텍스트 사용.

`spec:description`#

히스토리

GitLab 18.10에서 도입되었습니다.

키워드 유형: 헤더 키워드. spec은 설정 파일 상단의 헤더 섹션에 선언해야 합니다.

지원되는 값: 컴포넌트를 설명하는 문자열.

spec:description 예시:

spec:
  description: "A description of the component visible to users in the CI/CD Catalog."
  inputs:
    stage:
      default: test
---
scan-job:
  stage: $[[ inputs.stage ]]
  script: ./run-scan.sh

Job 키워드#

다음 항목은 키워드를 사용하여 CI/CD 파이프라인을 설정하는 방법을 설명합니다.

`after_script`#

히스토리

취소된 job에 대한 after_script 명령어 실행이 GitLab 17.0에서 도입되었습니다.

before_script 또는 script 섹션이 아직 실행 중인 동안 job이 취소된 경우.
job이 script_failure 유형의 실패로 실패하지만, 다른 실패 유형에서는 아닌 경우.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값: 다음을 포함하는 배열:

단일 줄 명령어.
여러 줄로 분할된 긴 명령어.
YAML 앵커.

CI/CD 변수는 지원됩니다.

after_script 예시:

job:
  script:
    - echo "An example script section."
  after_script:
    - echo "Execute this command after the `script` section completes."

추가 세부 정보:

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분으로 하드코딩되어 있습니다.
job의 종료 코드에 영향을 미치지 않습니다. script 섹션이 성공하고 after_script가 타임아웃되거나 실패하면, job은 코드 0(Job Succeeded)으로 종료됩니다.
after_script와 함께 CI/CD job 토큰을 사용하는 알려진 문제가 있습니다. after_script 명령어에서 인증에 job 토큰을 사용할 수 있지만, job이 취소되면 토큰이 즉시 무효화됩니다. 자세한 내용은 이슈를 참조하세요.
타임아웃된 job의 경우:
- after_script 명령어는 기본적으로 실행되지 않습니다.
- job의 타임아웃을 초과하지 않는 적절한 RUNNER_SCRIPT_TIMEOUT과 RUNNER_AFTER_SCRIPT_TIMEOUT 값을 설정하여 after_script가 실행되도록 타임아웃 값을 설정할 수 있습니다.
최상위 레벨에서 after_script를 사용하지만 default 섹션에서는 사용하지 않는 것은 더 이상 사용되지 않습니다.

실행 타이밍 및 파일 포함:

after_script 명령어는 캐시 및 아티팩트 업로드 작업 전에 실행됩니다.

아티팩트 수집을 설정한 경우:
- after_script에서 생성하거나 수정한 파일이 아티팩트에 포함됩니다.
- after_script에서 변경한 내용이 캐시 업로드에 포함됩니다.
after_script가 지정된 캐시 또는 아티팩트 경로에 생성하거나 수정하는 모든 파일이 캡처되고 업로드됩니다. 이 타이밍을 다음과 같은 시나리오에 사용할 수 있습니다:
- 메인 스크립트 후 테스트 보고서 또는 커버리지 데이터 생성.
- 요약 파일 또는 로그 생성.
- 빌드 출력물 후처리.

다음 예시에서, 포함되지 않는 유일한 파일은 아티팩트 또는 캐시 업로드 단계 후에 생성하거나 수정된 파일입니다:

job:
  script:
    - echo "main" > output.txt
    - build_something

  after_script:
    - echo "modified in after_script" >> output.txt  # This WILL be in the artifact
    - generate_test_report > report.html            # This WILL be in the artifact

  artifacts:
    paths:
      - output.txt
      - report.html

  cache:
    paths:
      - output.txt  # Will include the "modified in after_script" line

자세한 내용은 job 실행 흐름을 참조하세요.

관련 항목:

모든 job 후에 실행해야 할 기본 명령어 배열을 정의하려면 default와 함께 after_script 사용.
job이 취소된 경우 after_script 명령어를 건너뛰도록 job을 설정할 수 있습니다.
0이 아닌 종료 코드를 무시할 수 있습니다.
job 로그를 쉽게 검토할 수 있도록 after_script에 색상 코드 사용.
사용자 정의 접을 수 있는 섹션 생성으로 job 로그 출력 간소화.
after_script에서 오류를 무시할 수 있습니다.

`allow_failure`#

allow_failure를 사용하여 job이 실패할 때 파이프라인이 계속 실행될지 여부를 결정합니다.

파이프라인이 후속 job을 계속 실행하도록 하려면 allow_failure: true를 사용합니다.
파이프라인이 후속 job 실행을 중지하도록 하려면 allow_failure: false를 사용합니다.

이 동일한 경고는 다음 경우에도 표시됩니다:

Stage의 다른 모든 job이 성공한 경우.
파이프라인의 다른 모든 job이 성공한 경우.

allow_failure의 기본값은:

수동 job의 경우 true.
rules 내에서 when: manual을 사용하는 job의 경우 false.
다른 모든 경우 false.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

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 Stage의 job이 시작되지 않습니다.
job2가 실패하면, deploy Stage의 job이 여전히 시작될 수 있습니다.

추가 세부 정보:

allow_failure를 rules의 서브키로 사용할 수 있습니다.
allow_failure: true가 설정된 경우, job은 항상 성공으로 간주되며, 이 job이 실패해도 when: on_failure가 있는 이후 job은 시작되지 않습니다.
수동 job에 allow_failure: false를 사용하여 블로킹 수동 job을 만들 수 있습니다. 블로킹된 파이프라인은 수동 job이 시작되어 성공적으로 완료될 때까지 이후 Stage의 어떤 job도 실행하지 않습니다.

`allow_failure:exit_codes`#

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

단일 종료 코드.
종료 코드 배열.

allow_failure 예시:

test_job_1:
  script:
    - echo "Run a script that results in exit code 1. This job fails."
    - exit 1
  allow_failure:
    exit_codes: 137

test_job_2:
  script:
    - echo "Run a script that results in exit code 137. This job is allowed to fail."
    - exit 137
  allow_failure:
    exit_codes:
      - 137
      - 255

`artifacts`#

히스토리

GitLab Runner 18.1에서 업데이트되었습니다. 캐싱 프로세스 중에 이전 GitLab Runner 버전의 일부 엣지 케이스에서 발생했던 symlinks 추적이 더 이상 수행되지 않습니다.

job 아티팩트로 저장할 파일을 지정하려면 artifacts를 사용합니다. Job 아티팩트는 성공, 실패, 또는 항상 job에 첨부되는 파일 및 디렉토리 목록입니다.

아티팩트는 job이 완료된 후 GitLab으로 전송됩니다. 크기가 최대 아티팩트 크기보다 작으면 GitLab UI에서 다운로드할 수 있습니다.

needs 키워드를 사용할 때, job은 needs 설정에 정의된 job의 아티팩트만 다운로드할 수 있습니다.

Job 아티팩트는 기본적으로 성공한 job에 대해서만 수집되며, 아티팩트는 캐시 후에 복원됩니다.

아티팩트에 대해 더 읽어보기.

`artifacts:paths`#

경로는 프로젝트 디렉토리($CI_PROJECT_DIR)에 상대적이며 직접 외부에 링크할 수 없습니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

프로젝트 디렉토리에 상대적인 파일 경로 배열.
glob 패턴 및 doublestar.Glob 패턴을 사용하는 와일드카드를 사용할 수 있습니다.
GitLab Pages job의 경우:
- GitLab 17.10 이상에서, pages.publish 경로가 artifacts:paths에 자동으로 추가되므로 다시 지정할 필요가 없습니다.
- GitLab 17.10 이상에서, pages.publish 경로가 지정되지 않은 경우, public 디렉토리가 artifacts:paths에 자동으로 추가됩니다.

CI/CD 변수는 지원됩니다.

artifacts:paths 예시:

job:
  artifacts:
    paths:
      - binaries/
      - .config

이 예시는 .config와 binaries 디렉토리의 모든 파일로 아티팩트를 생성합니다.

추가 세부 정보:

artifacts:name과 함께 사용하지 않으면, 아티팩트 파일은 artifacts로 이름이 지정되며 다운로드 시 artifacts.zip이 됩니다.

관련 항목:

특정 job이 아티팩트를 가져오는 job을 제한하려면 dependencies를 참조하세요.
job 아티팩트 생성.

`artifacts:exclude`#

아티팩트 아카이브에 파일이 추가되지 않도록 하려면 artifacts:exclude를 사용합니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

프로젝트 디렉토리에 상대적인 파일 경로 배열.
glob 또는 doublestar.PathMatch 패턴을 사용하는 와일드카드를 사용할 수 있습니다.

artifacts:exclude 예시:

artifacts:
  paths:
    - binaries/
  exclude:
    - binaries/**/*.o

이 예시는 binaries/의 모든 파일을 저장하지만, binaries/의 하위 디렉토리에 있는 *.o 파일은 저장하지 않습니다.

추가 세부 정보:

artifacts:exclude 경로는 재귀적으로 검색되지 않습니다.
artifacts:untracked와 일치하는 파일은 artifacts:exclude를 사용하여 제외할 수도 있습니다.

관련 항목:

job 아티팩트에서 파일 제외.

`artifacts:expire_in`#

job 아티팩트가 만료되고 삭제되기 전에 저장되는 기간을 지정하려면 expire_in을 사용합니다. expire_in 설정은 다음에 영향을 미치지 않습니다:

프로젝트 수준 또는 인스턴스 전체에서 최신 job 아티팩트 유지가 비활성화된 경우를 제외하고, 최신 job의 아티팩트.

만료 후, 아티팩트는 기본적으로 매시간(cron job 사용) 삭제되며 더 이상 접근할 수 없습니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값: 만료 시간. 단위가 제공되지 않으면 시간은 초 단위입니다. 유효한 값은 다음과 같습니다:

'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에 저장될 때 시작됩니다. 만료 시간이 정의되지 않으면 인스턴스 전체 설정이 기본값입니다.
만료 날짜를 재정의하고 아티팩트가 자동으로 삭제되지 않도록 보호하려면:
- job 페이지에서 유지를 선택합니다.
- expire_in 값을 never로 설정합니다.
만료 시간이 너무 짧으면, 긴 파이프라인의 이후 Stage job이 이전 job의 만료된 아티팩트를 가져오려고 할 수 있습니다. 아티팩트가 만료되면, 가져오려는 job이 could not retrieve the needed artifacts 오류와 함께 실패합니다. 만료 시간을 더 길게 설정하거나, 이후 job에서 dependencies를 사용하여 만료된 아티팩트를 가져오지 않도록 합니다.
artifacts:expire_in은 GitLab Pages 배포에 영향을 미치지 않습니다. Pages 배포의 만료를 설정하려면 pages.expire_in을 사용합니다.

`artifacts:expose_as`#

머지 리퀘스트 UI에 아티팩트를 노출하려면 artifacts:expose_as 키워드를 사용합니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

아티팩트 다운로드 링크에 대해 머지 리퀘스트 UI에 표시할 이름. artifacts:paths와 함께 사용해야 합니다.

artifacts:expose_as 예시:

test:
  script: ["echo 'test' > file.txt"]
  artifacts:
    expose_as: 'artifact 1'
    paths: ['file.txt']

추가 세부 정보:

job당 expose_as를 한 번만 사용할 수 있으며, 머지 리퀘스트당 최대 10개의 job이 있습니다.
glob 패턴은 지원되지 않습니다.
아티팩트는 항상 GitLab으로 전송됩니다. artifacts:paths 값이 다음인 경우를 제외하고 UI에 표시됩니다:
- CI/CD 변수를 사용합니다.
- 디렉토리를 정의하지만 /로 끝나지 않습니다. 예를 들어, directory/는 artifacts:expose_as와 함께 작동하지만 directory는 작동하지 않습니다.
artifacts:paths에 단일 파일만 포함된 경우, 링크는 파일을 직접 엽니다. 다른 모든 경우, 링크는 아티팩트 브라우저를 엽니다.
링크된 파일은 기본적으로 다운로드됩니다. GitLab Pages가 활성화된 경우, 일부 아티팩트 파일 확장자를 브라우저에서 직접 미리 볼 수 있습니다. 자세한 내용은 아티팩트 아카이브 내용 탐색을 참조하세요.

관련 항목:

머지 리퀘스트 UI에 job 아티팩트 노출.

`artifacts:name`#

생성된 아티팩트 아카이브의 이름을 정의하려면 artifacts:name 키워드를 사용합니다. 모든 아카이브에 대해 고유한 이름을 지정할 수 있습니다.

정의되지 않은 경우, 기본 이름은 artifacts이며 다운로드 시 artifacts.zip이 됩니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

아티팩트 아카이브의 이름. CI/CD 변수는 지원됩니다. artifacts:paths와 함께 사용해야 합니다.

artifacts:name 예시:

현재 job 이름으로 아카이브를 생성하려면:

job:
  artifacts:
    name: "job1-artifacts-file"
    paths:
      - binaries/

관련 항목:

CI/CD 변수를 사용하여 아티팩트 설정 정의

`artifacts:public`#

히스토리

GitLab 15.10에서 업데이트되었습니다. 15.10 이전에 artifacts:public으로 생성된 아티팩트는 이 업데이트 후에도 비공개로 유지된다는 보장이 없습니다.
GitLab 16.7에서 일반 제공되었습니다. 기능 플래그 non_public_artifacts가 제거되었습니다.

Note

artifacts:public은 이제 더 많은 옵션을 가진 artifacts:access로 대체되었습니다.

Warning

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

true(기본값): 공개 파이프라인의 job 아티팩트는 익명 사용자 또는 Guest 및 Reporter 역할을 포함한 누구나 다운로드할 수 있습니다.
false: job의 아티팩트는 Developer, Maintainer, 또는 Owner 역할을 가진 사용자만 다운로드할 수 있습니다.

artifacts:public 예시:

job:
  artifacts:
    public: false

`artifacts:access`#

히스토리

GitLab 16.11에서 도입되었습니다.
maintainer 옵션이 GitLab 18.4에서 도입되었습니다.

동일한 job에서 artifacts:public과 artifacts:access를 사용할 수 없습니다.

Warning

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

all(기본값): 공개 파이프라인의 job 아티팩트는 익명, guest, reporter 사용자를 포함한 누구나 다운로드할 수 있습니다.
developer: job의 아티팩트는 Developer, Maintainer, 또는 Owner 역할을 가진 사용자만 다운로드할 수 있습니다.
maintainer: job의 아티팩트는 Maintainer 또는 Owner 역할을 가진 사용자만 다운로드할 수 있습니다.
none: 누구도 job의 아티팩트를 다운로드할 수 없습니다.

artifacts:access 예시:

job:
  artifacts:
    access: 'developer'

추가 세부 정보:

artifacts:access는 모든 artifacts:reports에도 영향을 미치므로, 보고서용 아티팩트에 대한 접근도 제한할 수 있습니다.

`artifacts:reports`#

job에 포함된 템플릿이 생성한 아티팩트를 수집하려면 artifacts:reports를 사용합니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

사용 가능한 아티팩트 보고서 유형 목록 참조.

artifacts:reports 예시:

rspec:
  stage: test
  script:
    - bundle install
    - rspec --format RspecJunitFormatter --out rspec.xml
  artifacts:
    reports:
      junit: rspec.xml

추가 세부 정보:

자식 파이프라인의 아티팩트를 사용하여 상위 파이프라인에서 보고서를 결합하는 것은 지원되지 않습니다. 지원 추가 진행 상황은 이 이슈에서 추적합니다.
보고서 출력 파일을 탐색하고 다운로드할 수 있으려면 artifacts:paths 키워드를 포함합니다. 이렇게 하면 아티팩트가 두 번 업로드되고 저장됩니다.
artifacts: reports로 생성된 아티팩트는 job 결과(성공 또는 실패)에 관계없이 항상 업로드됩니다. artifacts:expire_in을 사용하여 아티팩트의 만료 날짜를 설정할 수 있습니다.

`artifacts:untracked`#

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

true 또는 false(정의되지 않은 경우 기본값).

artifacts:untracked 예시:

모든 Git 추적되지 않은 파일 저장:

job:
  artifacts:
    untracked: true

관련 항목:

추적되지 않은 파일을 아티팩트에 추가.

`artifacts:when`#

job 실패 시 또는 실패에도 불구하고 아티팩트를 업로드하려면 artifacts:when을 사용합니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

on_success(기본값): job이 성공할 때만 아티팩트를 업로드합니다.
on_failure: job이 실패할 때만 아티팩트를 업로드합니다.
always: 항상 아티팩트를 업로드합니다(job 타임아웃 제외). 예를 들어, 실패한 테스트 문제를 해결하는 데 필요한 아티팩트를 업로드할 때.

artifacts:when 예시:

job:
  artifacts:
    when: on_failure

추가 세부 정보:

artifacts:reports로 생성된 아티팩트는 job 결과(성공 또는 실패)에 관계없이 항상 업로드됩니다. artifacts:when은 이 동작을 변경하지 않습니다.

`before_script`#

각 job의 script 명령어 전에, 하지만 아티팩트가 복원된 후에 실행해야 할 명령어 배열을 정의하려면 before_script를 사용합니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값: 다음을 포함하는 배열:

단일 줄 명령어.
여러 줄로 분할된 긴 명령어.
YAML 앵커.

CI/CD 변수는 지원됩니다.

before_script 예시:

job:
  before_script:
    - echo "Execute this command before any 'script:' commands."
  script:
    - echo "This command executes after the job's 'before_script' commands."

추가 세부 정보:

before_script에 지정한 스크립트는 메인 script에 지정한 스크립트와 연결됩니다. 결합된 스크립트가 단일 셸에서 함께 실행됩니다.
최상위 레벨에서 before_script를 사용하지만 default 섹션에서는 사용하지 않는 것은 더 이상 사용되지 않습니다.

관련 항목:

모든 job의 script 명령어 전에 실행해야 할 기본 명령어 배열을 정의하려면 default와 함께 before_script 사용.
- Job 설정과 기본 설정은 병합되지 않습니다. 파이프라인에 default:before_script가 정의되어 있고 job에도 before_script가 있는 경우, job 설정이 우선하고 기본 설정은 사용되지 않습니다.
0이 아닌 종료 코드를 무시할 수 있습니다.
job 로그를 쉽게 검토할 수 있도록 before_script에 색상 코드 사용.
사용자 정의 접을 수 있는 섹션 생성으로 job 로그 출력 간소화.

`cache`#

히스토리

GitLab 15.0에서 도입되었습니다. 캐시는 보호된 브랜치와 보호되지 않은 브랜치 간에 공유되지 않습니다.
GitLab Runner 18.1에서 업데이트되었습니다. 캐싱 프로세스 중에 이전 GitLab Runner 버전의 일부 엣지 케이스에서 발생했던 symlinks 추적이 더 이상 수행되지 않습니다.

job 간에 캐시할 파일 및 디렉토리 목록을 지정하려면 cache를 사용합니다. 로컬 작업 복사본에 있는 경로만 사용할 수 있습니다.

캐시는:

파이프라인과 job 간에 공유됩니다.
기본적으로 보호된 브랜치와 보호되지 않은 브랜치 간에 공유되지 않습니다.
아티팩트 전에 복원됩니다.
최대 4개의 다른 캐시로 제한됩니다.

예를 들어 다음을 재정의하기 위해 특정 job에 대한 캐싱을 비활성화할 수 있습니다:

default로 정의된 기본 캐시.
include로 추가된 job 설정.

캐시에 대한 자세한 내용은 GitLab CI/CD에서의 캐싱을 참조하세요.

최상위 레벨에서 cache를 사용하지만 default 섹션에서는 사용하지 않는 것은 더 이상 사용되지 않습니다.

`cache:paths`#

캐시할 파일 또는 디렉토리를 선택하려면 cache:paths 키워드를 사용합니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

프로젝트 디렉토리($CI_PROJECT_DIR)에 상대적인 경로 배열. glob 및 doublestar.Glob 패턴을 사용하는 와일드카드를 사용할 수 있습니다.

CI/CD 변수가 지원됩니다.

cache:paths 예시:

.apk로 끝나는 binaries의 모든 파일과 .config 파일을 캐시합니다:

rspec:
  script:
    - echo "This job uses a cache."
  cache:
    key: binaries-cache
    paths:
      - binaries/*.apk
      - .config

추가 세부 정보:

cache:paths 키워드는 추적되지 않은 파일이나 .gitignore 파일에 있는 파일도 포함합니다.

관련 항목:

더 많은 cache:paths 예시는 CI/CD 캐싱 예시를 참조하세요.

`cache:key`#

설정되지 않으면, 기본 키는 default입니다. cache 키워드가 있지만 cache:key가 없는 모든 job은 default 캐시를 공유합니다.

cache: paths와 함께 사용해야 하며, 그렇지 않으면 아무것도 캐시되지 않습니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

문자열.
사전 정의된 CI/CD 변수.
두 가지의 조합.

cache:key 예시:

cache-job:
  script:
    - echo "This job uses a cache."
  cache:
    key: binaries-cache-$CI_COMMIT_REF_SLUG
    paths:
      - binaries/

추가 세부 정보:

Windows Batch를 사용하여 셸 스크립트를 실행하는 경우 $를 %로 바꿔야 합니다. 예: key: %CI_COMMIT_REF_SLUG%
cache:key 값에는 다음을 포함할 수 없습니다:
- / 문자 또는 동등한 URI 인코딩 %2F.
- . 문자만 있는 경우(임의 수), 또는 동등한 URI 인코딩 %2E.
캐시는 job 간에 공유되므로, 다른 job에 대해 다른 경로를 사용하는 경우 다른 cache:key도 설정해야 합니다. 그렇지 않으면 캐시 내용이 덮어씌워질 수 있습니다.

관련 항목:

지정된 cache:key를 찾을 수 없는 경우 사용할 대체 캐시 키를 지정할 수 있습니다.
단일 job에서 여러 캐시 키를 사용할 수 있습니다.
더 많은 cache:key 예시는 CI/CD 캐싱 예시를 참조하세요.

`cache:key:files`#

키워드 유형: Job 키워드. job의 일부로 또는 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

추가 세부 정보:

캐시 key는 나열된 파일의 내용에서 계산된 SHA입니다. 파일이 없으면 키 계산에서 무시됩니다. 지정된 파일 중 아무것도 없으면 대체 키는 default입니다.
**/package.json과 같은 와일드카드 패턴을 사용할 수 있습니다. 캐시 키에 허용되는 경로 또는 패턴 수를 늘리기 위한 이슈가 있습니다.

`cache:key:files_commits`#

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

최대 두 개의 파일 경로 또는 패턴 배열.

cache:key:files_commits 예시:

cache-job:
  script:
    - echo "This job uses a commit-based cache."
  cache:
    key:
      files_commits:
        - package.json
        - yarn.lock
    paths:
      - node_modules

추가 세부 정보:

캐시 key는 각 지정된 파일의 가장 최근 커밋에서 계산된 SHA입니다.
파일이 없으면 키 계산에서 무시됩니다.
지정된 파일 중 아무것도 없으면 대체 키는 default입니다.
동일한 캐시 설정에서 cache:key:files와 함께 사용할 수 없습니다.

`cache:key:prefix`#

cache:key:prefix를 사용하여 cache:key:files에 대해 계산된 SHA와 접두사를 결합합니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

문자열.
사전 정의된 CI/CD 변수.
두 가지의 조합.

cache:key:prefix 예시:

rspec:
  script:
    - echo "This rspec job uses a cache."
  cache:
    key:
      files:
        - Gemfile.lock
      prefix: $CI_JOB_NAME
    paths:
      - vendor/ruby

추가 세부 정보:

cache:key:files의 파일이 커밋에서 변경되지 않은 경우, 접두사가 default 키에 추가됩니다.

`cache:untracked`#

Git 리포지터리에서 추적되지 않은 모든 파일을 캐시하려면 untracked: true를 사용합니다. 추적되지 않은 파일에는 다음이 포함됩니다:

.gitignore 설정으로 인해 무시된 파일.
생성되었지만 git add로 체크아웃에 추가되지 않은 파일.

job이 다음을 다운로드하는 경우 추적되지 않은 파일 캐싱이 예상보다 큰 캐시를 생성할 수 있습니다:

gem이나 node 모듈과 같이 일반적으로 추적되지 않은 종속성.
다른 job의 아티팩트. 아티팩트에서 추출된 파일은 기본적으로 추적되지 않습니다.

키워드 유형: Job 키워드. job의 일부로 또는 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/
```
이 예시에서 job은 리포지터리의 모든 추적되지 않은 파일과 binaries/의 모든 파일을 캐시합니다. binaries/에 추적되지 않은 파일이 있으면, 두 키워드 모두에 포함됩니다.

`cache:unprotect`#

히스토리

GitLab 15.8에서 도입되었습니다.

보호된 브랜치와 보호되지 않은 브랜치 간에 캐시를 공유하도록 설정하려면 cache:unprotect를 사용합니다.

Warning

true로 설정하면, 보호된 브랜치에 대한 접근 권한이 없는 사용자가 보호된 브랜치가 사용하는 캐시 키에 읽고 쓸 수 있습니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

true 또는 false(기본값).

cache:unprotect 예시:

rspec:
  script: test
  cache:
    unprotect: true

`cache:when`#

job 상태에 따라 캐시를 저장할 시기를 정의하려면 cache:when을 사용합니다.

cache: paths와 함께 사용해야 하며, 그렇지 않으면 아무것도 캐시되지 않습니다.

키워드 유형: Job 키워드. job의 일부로 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

on_success(기본값): job이 성공할 때만 캐시를 저장합니다.
on_failure: job이 실패할 때만 캐시를 저장합니다.
always: 항상 캐시를 저장합니다.

cache:when 예시:

rspec:
  script: rspec
  cache:
    paths:
      - rspec/
    when: 'always'

이 예시는 job이 실패하든 성공하든 캐시를 저장합니다.

`cache:policy`#

job이 시작될 때만 캐시를 다운로드하지만 job이 완료될 때 변경 사항을 업로드하지 않도록 설정하려면 cache:policy:pull을 사용합니다.

job이 완료될 때만 캐시를 업로드하지만 job이 시작될 때 캐시를 다운로드하지 않도록 설정하려면 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..."

관련 항목:

변수를 사용하여 job의 캐시 정책 제어.

`cache: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`#

일치에서 코드 커버리지 값을 추출하기 위해 GitLab은 이 더 작은 정규 표현식을 사용합니다: \d+(?:\.\d+)?.

지원되는 값:

RE2 정규 표현식. /로 시작하고 끝나야 합니다. 커버리지 번호와 일치해야 합니다. 주변 텍스트와도 일치할 수 있으므로, 정확한 번호를 캡처하기 위해 정규 표현식 문자 그룹을 사용할 필요가 없습니다. RE2 문법을 사용하므로 모든 그룹은 비캡처여야 합니다.

coverage 예시:

job1:
  script: rspec
  coverage: '/Code coverage: \d+(?:\.\d+)?/'

이 예시에서:

GitLab은 정규 표현식과 일치하는 job 로그를 확인합니다. Code coverage: 67.89% of lines covered와 같은 줄이 일치합니다.
GitLab은 정규 표현식과 일치하는 항목을 찾기 위해 일치하는 단편을 확인합니다: \d+(?:\.\d+)?. 샘플 정규 표현식은 67.89의 코드 커버리지와 일치할 수 있습니다.

추가 세부 정보:

코드 커버리지에서 정규 표현식 예시를 찾을 수 있습니다.
job 출력에 일치하는 줄이 두 개 이상 있으면 마지막 줄이 사용됩니다(역방향 검색의 첫 번째 결과).
단일 줄에 여러 일치가 있으면 마지막 일치에서 커버리지 번호가 검색됩니다.
일치하는 단편에서 여러 커버리지 번호가 발견되면 첫 번째 번호가 사용됩니다.
선행 0이 제거됩니다.
자식 파이프라인의 커버리지 출력은 기록되거나 표시되지 않습니다. 자세한 내용은 관련 이슈를 확인하세요.

`dast_configuration`#

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값: site_profile과 scanner_profile 각각 하나씩.

job에서 사용할 사이트 프로필을 지정하려면 site_profile을 사용합니다.
job에서 사용할 스캐너 프로필을 지정하려면 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 job은 include 키워드로 추가된 dast 설정을 확장하여 특정 사이트 프로필과 스캐너 프로필을 선택합니다.

추가 세부 정보:

사이트 프로필 또는 스캐너 프로필에 포함된 설정은 DAST 템플릿에 포함된 설정보다 우선합니다.

관련 항목:

`dependencies`#

dependencies가 job에 정의되지 않으면, 이전 Stage의 모든 job이 종속된 것으로 간주되고 job은 해당 job에서 모든 아티팩트를 가져옵니다.

동일한 Stage의 job에서 아티팩트를 가져오려면 needs:artifacts를 사용해야 합니다. 동일한 job에서 dependencies와 needs를 결합하지 않아야 합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

아티팩트를 가져올 job 이름.
어떤 아티팩트도 다운로드하지 않도록 job을 설정하는 빈 배열([]).

dependencies 예시:

build mac:
  stage: build
  script: make build:mac
  artifacts:
    paths:
      - binaries/

build linux:
  stage: build
  script: make build:linux
  artifacts:
    paths:
      - binaries/

test mac:
  stage: test
  script: make test:mac
  dependencies:
    - build mac

test linux:
  stage: test
  script: make test:linux
  dependencies:
    - build linux

deploy:
  stage: deploy
  script: make deploy
  environment: production

deploy job은 Stage 우선 순위로 인해 모든 이전 job에서 아티팩트를 다운로드합니다.

추가 세부 정보:

job 상태는 중요하지 않습니다. job이 실패하거나 트리거되지 않은 수동 job이어도 오류가 발생하지 않습니다.
종속된 job의 아티팩트가 만료되거나 삭제되면 job이 실패합니다.

`environment`#

job이 배포하는 환경을 정의하려면 environment를 사용합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값: job이 배포하는 환경의 이름, 다음 형식 중 하나:

문자, 숫자, 공백 및 다음 문자를 포함하는 일반 텍스트: -, _, /, $, {, }.
사전 정의된, 프로젝트, 그룹, 인스턴스 또는 .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이지만 원하는 이름을 사용할 수 있습니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값: job이 배포하는 환경의 이름, 다음 형식 중 하나:

문자, 숫자, 공백 및 다음 문자를 포함하는 일반 텍스트: -, _, /, $, {, }.
사전 정의된, 프로젝트, 그룹, 인스턴스 또는 .gitlab-ci.yml 파일에 정의된 변수를 포함하는 CI/CD 변수. 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과 같은 일반 텍스트.
사전 정의된, 프로젝트, 그룹, 인스턴스 또는 .gitlab-ci.yml 파일에 정의된 변수를 포함하는 CI/CD 변수. script 섹션에서 정의된 변수는 사용할 수 없습니다.

environment:url 예시:

deploy to production:
  stage: deploy
  script: git push production HEAD:main
  environment:
    name: production
    url: https://prod.example.com

추가 세부 정보:

job이 완료되면, 머지 리퀘스트, 환경 또는 배포 페이지에서 버튼을 선택하여 URL에 접근할 수 있습니다.

`environment:on_stop`#

환경 종료(중지)는 environment 아래에 정의된 on_stop 키워드로 달성할 수 있습니다. 환경을 닫기 위해 실행되는 다른 job을 선언합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

추가 세부 정보:

자세한 내용과 예시는 environment:action을 참조하세요.

`environment:action`#

job이 환경과 어떻게 상호작용하는지 지정하려면 action 키워드를 사용합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값: 다음 키워드 중 하나:

값	설명
`start`	기본값. job이 환경을 시작함을 나타냅니다. job이 시작된 후 배포가 생성됩니다.
`prepare`	job이 환경을 준비하기만 한다는 것을 나타냅니다. 배포를 트리거하지 않습니다. 환경 준비에 대한 자세한 내용.
`stop`	job이 환경을 중지함을 나타냅니다. 환경 중지에 대한 자세한 내용.
`verify`	job이 환경을 확인하기만 한다는 것을 나타냅니다. 배포를 트리거하지 않습니다. 환경 확인에 대한 자세한 내용.
`access`	job이 환경에만 접근한다는 것을 나타냅니다. 배포를 트리거하지 않습니다. 환경 접근에 대한 자세한 내용.

environment:action 예시:

stop_review_app:
  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`#

히스토리

CI/CD 변수 지원이 GitLab 15.4에서 도입되었습니다.
GitLab 17.7에서 prepare, access, verify 환경 액션을 지원하도록 업데이트되었습니다.

auto_stop_in 키워드는 환경의 수명을 지정합니다. 환경이 만료되면, GitLab이 자동으로 중지합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값: 자연어로 작성된 기간. 예를 들어, 이것들은 모두 동일합니다:

168 hours
7 days
one week
never

CI/CD 변수는 지원됩니다.

environment:auto_stop_in 예시:

review_app:
  script: deploy-review-app
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    auto_stop_in: 1 day

review_app의 환경이 생성되면, 환경의 수명이 1 day로 설정됩니다. 리뷰 앱이 배포될 때마다 해당 수명도 1 day로 재설정됩니다.

관련 항목:

환경 자동 중지 문서.

`environment:kubernetes`#

히스토리

agent 키워드가 GitLab 17.6에서 도입되었습니다.
namespace 및 flux_resource_path 키워드가 GitLab 17.7에서 도입되었습니다.
namespace 및 flux_resource_path 키워드가 GitLab 18.4에서 더 이상 사용되지 않습니다.
dashboard:namespace 및 dashboard:flux_resource_path 키워드가 GitLab 18.4에서 도입되었습니다.

kubernetes 키워드를 사용하여 환경에 대한 Kubernetes 대시보드와 GitLab 관리 Kubernetes 리소스를 구성합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

agent: Kubernetes용 GitLab 에이전트를 지정하는 문자열. 형식은 path/to/agent/project:agent-name입니다. 에이전트가 파이프라인을 실행하는 프로젝트에 연결되어 있으면 $CI_PROJECT_PATH:agent-name을 사용하세요.
dashboard:namespace: 환경이 배포된 Kubernetes 네임스페이스를 나타내는 문자열. 네임스페이스는 agent 키워드와 함께 설정해야 합니다. namespace는 더 이상 사용되지 않습니다.
dashboard:flux_resource_path: HelmRelease 같은 Flux 리소스의 전체 경로를 나타내는 문자열. Flux 리소스는 agent 및 dashboard:namespace 키워드와 함께 설정해야 합니다. flux_resource_path는 더 이상 사용되지 않습니다.
managed_resources: enabled 키워드가 있는 해시로, 환경에 대한 GitLab 관리 Kubernetes 리소스를 구성합니다.
- managed_resources:enabled: GitLab 관리 Kubernetes 리소스가 환경에서 활성화되어 있는지 여부를 나타내는 불리언 값.
dashboard: 환경에 대한 Kubernetes 대시보드를 구성하는 dashboard:namespace 및 dashboard:flux_resource_path 키워드가 있는 해시.

environment:kubernetes 예시:

deploy:
  stage: deploy
  script: make deploy-app
  environment:
    name: production
    kubernetes:
      agent: path/to/agent/project:agent-name
      dashboard:
        namespace: my-namespace
        flux_resource_path: helm.toolkit.fluxcd.io/v2/namespaces/flux-system/helmreleases/helm-release-resource

관리 리소스를 비활성화하는 경우의 environment:kubernetes 예시:

deploy:
  stage: deploy
  script: make deploy-app
  environment:
    name: production
    kubernetes:
      agent: path/to/agent/project:agent-name
      managed_resources:
        enabled: false
      dashboard:
        namespace: my-namespace
        flux_resource_path: helm.toolkit.fluxcd.io/v2/namespaces/flux-system/helmreleases/helm-release-resource

이 구성은 다음을 수행합니다:

deploy job을 production 환경에 배포하도록 설정합니다.
agent-name이라는 에이전트를 환경과 연결합니다.
네임스페이스 my-namespace와 helm.toolkit.fluxcd.io/v2/namespaces/flux-system/helmreleases/helm-release-resource로 설정된 flux_resource_path로 환경에 대한 Kubernetes 대시보드를 구성합니다.

추가 세부 정보:

대시보드를 사용하려면 Kubernetes용 GitLab 에이전트를 설치하고 환경의 프로젝트 또는 상위 그룹에 대해 user_access를 구성해야 합니다.
job을 실행하는 사용자는 클러스터 에이전트에 액세스할 수 있는 권한이 있어야 합니다. 그렇지 않으면 대시보드는 agent, namespace, flux_resource_path 속성을 무시합니다.
agent만 설정하려면 namespace를 설정할 필요가 없으며 flux_resource_path는 설정할 수 없습니다. 하지만 이 구성은 Kubernetes 대시보드에서 클러스터의 모든 네임스페이스를 나열합니다.

`environment:deployment_tier`#

히스토리

CI/CD 변수 지원이 GitLab 18.5에서 추가되었습니다.

deployment_tier 키워드를 사용하여 배포 환경의 계층을 지정합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값: 다음 중 하나:

production
staging
testing
development
other
CI/CD 변수 (사전 정의된 변수, 프로젝트, 그룹, 인스턴스 변수, 또는 .gitlab-ci.yml 파일에 정의된 변수 포함). script 섹션에서 정의된 변수는 사용할 수 없습니다.

environment:deployment_tier 예시:

deploy:
  script: echo
  environment:
    name: customer-portal
    deployment_tier: production

추가 세부 정보:

이 job 정의에서 생성된 환경에는 이 값을 기반으로 계층이 할당됩니다.
이 값이 나중에 추가된 경우 기존 환경의 계층은 업데이트되지 않습니다. 기존 환경의 계층은 Environments API를 통해 업데이트해야 합니다.

관련 항목:

환경의 배포 계층.

동적 환경#

CI/CD 변수를 사용하여 환경 이름을 동적으로 지정합니다.

예시:

deploy as review app:
  stage: deploy
  script: make deploy
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_ENVIRONMENT_SLUG.example.com/

`extends`#

extends를 사용하여 구성 섹션을 재사용합니다. 이는 YAML 앵커의 대안이며 좀 더 유연하고 읽기 쉽습니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

파이프라인에 있는 다른 job의 이름.
파이프라인에 있는 다른 job 이름의 목록(배열).

extends 예시:

.tests:
  stage: test
  image: ruby:3.0

rspec:
  extends: .tests
  script: rake rspec

rubocop:
  extends: .tests
  script: bundle exec rubocop

이 예시에서 rspec job은 .tests 템플릿 job의 구성을 사용합니다. 파이프라인을 생성할 때 GitLab은 다음을 수행합니다:

키를 기반으로 역방향 깊은 병합을 수행합니다.
.tests 내용을 rspec job과 병합합니다.
키 값은 병합하지 않습니다.

결합된 구성은 다음 job과 동일합니다:

rspec:
  stage: test
  image: ruby:3.0
  script: rake rspec

rubocop:
  stage: test
  image: ruby:3.0
  script: bundle exec rubocop

추가 세부 정보:

extends에 여러 부모를 사용할 수 있습니다.
extends 키워드는 최대 11단계 상속을 지원하지만 세 단계를 초과하여 사용하는 것은 피하는 것이 좋습니다.
이전 예시에서 .tests는 히든 job이지만 일반 job의 구성도 확장할 수 있습니다.

관련 항목:

extends를 사용하여 구성 섹션 재사용.
extends를 사용하여 포함된 구성 파일에서 구성 재사용.

`hooks`#

히스토리

GitLab 15.6에서 ci_hooks_pre_get_sources_script라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
GitLab 15.10에서 일반 공개되었습니다. 기능 플래그 ci_hooks_pre_get_sources_script가 제거되었습니다.

hooks를 사용하여 Git 리포지터리를 가져오기 전과 같이 job 실행의 특정 단계에서 러너에서 실행할 명령 목록을 지정합니다.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

hooks와 명령의 해시. 사용 가능한 hooks: 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가 제거되었습니다.

Git 구성 조정.
추적 변수 내보내기.

지원되는 값: 다음을 포함하는 배열:

단일 줄 명령.
여러 줄로 분할된 긴 명령.
YAML 앵커.

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'

관련 항목:

GitLab Runner 구성

`identity`#

히스토리

GitLab 16.9에서 google_cloud_support_feature_flag라는 플래그와 함께 도입되었습니다. 이 기능은 베타 상태입니다.
GitLab 17.1에서 GitLab.com에서 활성화되었습니다. 기능 플래그 google_cloud_support_feature_flag가 제거되었습니다.

이 기능은 베타 상태입니다.

identity를 사용하여 ID 페더레이션을 통해 타사 서비스에 인증합니다.

키워드 유형: 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에서 도입되었습니다.

지원되는 값:

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를 사용하여 job이 실행되는 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

추가 세부 정보:

default 섹션이 아닌 최상위 수준에서 image를 사용하는 것은 더 이상 사용되지 않습니다.

관련 항목:

Docker 컨테이너에서 CI/CD job 실행.

`image:name`#

job이 실행되는 Docker 이미지 이름. 단독으로 사용되는 image와 유사합니다.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값: 필요한 경우 레지스트리 경로를 포함한 이미지 이름, 다음 형식 중 하나로:

<image-name> (latest 태그와 함께 <image-name> 사용과 동일)
<image-name>:<tag>
<image-name>@<digest>

CI/CD 변수는 지원됩니다.

image:name 예시:

test-job:
  image:
    name: "registry.example.com/my/image:latest"
  script: echo "Hello world"

관련 항목:

Docker 컨테이너에서 CI/CD job 실행.

`image:entrypoint`#

컨테이너의 엔트리포인트로 실행할 명령 또는 스크립트.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

문자열.

image:entrypoint 예시:

test-job:
  image:
    name: super/sql:experimental
    entrypoint: [""]
  script: echo "Hello world"

관련 항목:

이미지의 엔트리포인트 재정의.

`image:docker`#

히스토리

GitLab 16.7에서 도입되었습니다. GitLab Runner 16.7 이상이 필요합니다.
user 입력 옵션이 GitLab 16.8에서 도입되었습니다.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

Docker executor에 대한 옵션의 해시, 다음을 포함할 수 있습니다:

platform: 가져올 이미지의 아키텍처를 선택합니다. 지정하지 않으면 기본값은 호스트 러너와 동일한 플랫폼입니다.
user: 컨테이너를 실행할 때 사용할 사용자 이름 또는 UID를 지정합니다.

image:docker 예시:

arm-sql-job:
  script: echo "Run sql tests"
  image:
    name: super/sql:experimental
    docker:
      platform: arm64/v8
      user: dave

추가 세부 정보:

image:docker:platform은 docker pull --platform 옵션에 매핑됩니다.
image:docker:user는 docker run --user 옵션에 매핑됩니다.

`image:kubernetes`#

히스토리

GitLab 18.0에서 도입되었습니다. GitLab Runner 17.11 이상이 필요합니다.
user 입력 옵션이 GitLab Runner 17.11에서 도입되었습니다.
user 입력 옵션이 GitLab 18.0에서 uid:gid 형식을 지원하도록 확장되었습니다.

image:kubernetes를 사용하여 GitLab Runner Kubernetes executor에 옵션을 전달합니다. 이 키워드는 다른 executor 유형에서는 작동하지 않습니다.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

Kubernetes executor에 대한 옵션의 해시, 다음을 포함할 수 있습니다:

user: 컨테이너가 실행될 때 사용할 사용자 이름 또는 UID를 지정합니다. UID:GID 형식을 사용하여 GID를 설정할 수도 있습니다.

UID만 사용하는 image:kubernetes 예시:

arm-sql-job:
  script: echo "Run sql tests"
  image:
    name: super/sql:experimental
    kubernetes:
      user: "1001"

UID와 GID 모두 사용하는 image:kubernetes 예시:

arm-sql-job:
  script: echo "Run sql tests"
  image:
    name: super/sql:experimental
    kubernetes:
      user: "1001:1001"

`image:pull_policy`#

히스토리

GitLab 15.1에서 ci_docker_image_pull_policy라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
GitLab 15.2에서 GitLab.com 및 GitLab Self-Managed에서 활성화되었습니다.
GitLab 15.4에서 일반 공개되었습니다. 기능 플래그 ci_docker_image_pull_policy가 제거되었습니다.
GitLab Runner 15.1 이상이 필요합니다.

러너가 Docker 이미지를 가져오는 데 사용하는 풀 정책.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

단일 풀 정책 또는 배열의 여러 풀 정책. always, if-not-present, 또는 never일 수 있습니다.

image:pull_policy 예시:

job1:
  script: echo "A single pull policy."
  image:
    name: ruby:3.0
    pull_policy: if-not-present

job2:
  script: echo "Multiple pull policies."
  image:
    name: ruby:3.0
    pull_policy: [always, if-not-present]

추가 세부 정보:

러너가 정의된 풀 정책을 지원하지 않으면 job이 다음과 유사한 오류와 함께 실패합니다: ERROR: Job failed (system failure): the configured PullPolicies ([always]) are not allowed by AllowedPullPolicies ([never]).

관련 항목:

`inputs`#

히스토리

GitLab 18.10에서 도입되었습니다.

inputs를 사용하여 job에 대한 타입 지정 및 검증된 입력값을 정의합니다. Job 입력값은 job을 수동으로 실행하거나 재시도할 때 재정의할 수 있습니다.

${{ job.inputs.INPUT_NAME }} Moa 표현식 구문으로 job 입력값을 참조합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

입력값 이름의 해시, 각 입력값은 하나 이상의 하위 키로 구성됩니다:

default (필수)
type
options
description
regex

inputs 예시:

test_job:
  inputs:
    test_suite:
      default: unit
      description: Which test suite to run
      options: [unit, integration, e2e]
    parallel_count:
      type: number
      default: 5
      description: Number of parallel test runners
    verbose:
      type: boolean
      default: false
      description: Enable verbose test output
  script:
    - 'echo "Running ${{ job.inputs.test_suite }} tests"'
    - 'if [ "${{ job.inputs.verbose }}" == "true" ]; then export TEST_VERBOSE=1; fi'
    - ./run_tests.sh --suite ${{ job.inputs.test_suite }} --parallel ${{ job.inputs.parallel_count }}

추가 세부 정보:

Job 입력값은 job이 생성될 때와 새 입력값으로 job을 재시도하려고 할 때 검증됩니다. 유효성 검사가 실패하면 job이 시작되지 않습니다.
Job 입력값은 정의된 job에만 적용되며 다른 job에서는 접근할 수 없습니다.
job 입력값을 지원하는 키워드의 전체 목록은 job 입력값을 사용할 수 있는 곳을 참조하세요.

`inputs:default`#

모든 job 입력값은 default로 정의된 기본값이 있어야 합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값: 입력값의 type과 일치하는 모든 값.

inputs:default 예시:

test_job:
  inputs:
    environment:
      default: staging
    timeout:
      type: number
      default: 30

`inputs:type`#

type을 사용하여 입력값의 데이터 타입을 정의합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

string (기본값)
number
boolean
array.

inputs:type 예시:

test_job:
  inputs:
    count:
      type: number
      default: 5
    enabled:
      type: boolean
      default: true

`inputs:description`#

description을 사용하여 입력값의 목적에 대한 정보를 제공합니다. 설명은 입력값의 동작에 영향을 주지 않습니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값: 문자열.

inputs:description 예시:

deploy_job:
  inputs:
    environment:
      default: staging
      description: Target deployment environment

`inputs:options`#

options를 사용하여 입력값에 허용되는 값 목록을 지정합니다.

입력값은 나열된 옵션 중 하나와 정확히 일치해야 합니다(대소문자 구분). 값이 옵션과 일치하지 않으면 유효성 검사가 실패합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값: 허용되는 값의 배열.

inputs:options 예시:

deploy_job:
  inputs:
    environment:
      default: staging
      options: [development, staging, production]

`inputs:regex`#

regex를 사용하여 입력값이 일치해야 하는 정규 표현식 패턴을 지정합니다.

값이 정규 표현식과 일치하지 않으면 유효성 검사가 실패합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값: 정규 표현식 문자열.

inputs:regex 예시:

deploy_job:
  inputs:
    version:
      default: v1.0.0
      regex: ^v\d+\.\d+\.\d+$

이 예시에서 v1.1.1의 입력값은 정규 표현식 유효성 검사를 통과하지만 v1.1.1-beta는 통과하지 못합니다.

`inherit`#

inherit를 사용하여 기본 키워드와 변수의 상속을 제어합니다.

`inherit:default`#

inherit:default를 사용하여 기본 키워드의 상속을 제어합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

true (기본값) 또는 false로 모든 기본 키워드의 상속을 활성화하거나 비활성화합니다.
상속할 특정 기본 키워드 목록.

inherit:default 예시:

default:
  retry: 2
  image: ruby:3.0
  interruptible: true

job1:
  script: echo "This job does not inherit any default keywords."
  inherit:
    default: false

job2:
  script: echo "This job inherits only the two listed default keywords. It does not inherit 'interruptible'."
  inherit:
    default:
      - retry
      - image

추가 세부 정보:

상속할 기본 키워드를 한 줄에 나열할 수도 있습니다: default: [keyword1, keyword2]

`inherit:variables`#

inherit:variables를 사용하여 기본 변수 키워드의 상속을 제어합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

true (기본값) 또는 false로 모든 기본 변수의 상속을 활성화하거나 비활성화합니다.
상속할 특정 변수 목록.

inherit:variables 예시:

variables:
  VARIABLE1: "This is default variable 1"
  VARIABLE2: "This is default variable 2"
  VARIABLE3: "This is default variable 3"

job1:
  script: echo "This job does not inherit any default variables."
  inherit:
    variables: false

job2:
  script: echo "This job inherits only the two listed default variables. It does not inherit 'VARIABLE3'."
  inherit:
    variables:
      - VARIABLE1
      - VARIABLE2

추가 세부 정보:

상속할 기본 변수를 한 줄에 나열할 수도 있습니다: variables: [VARIABLE1, VARIABLE2]

`interruptible`#

히스토리

trigger job에 대한 지원이 GitLab 16.8에서 도입되었습니다.

중복 파이프라인 자동 취소 기능의 동작은 workflow:auto_cancel:on_new_commit 설정으로 제어할 수 있습니다.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

true 또는 false (기본값).

기본 동작의 interruptible 예시:

workflow:
  auto_cancel:
    on_new_commit: conservative # the default behavior

stages:
  - stage1
  - stage2
  - stage3

step-1:
  stage: stage1
  script:
    - echo "Can be canceled."
  interruptible: true

step-2:
  stage: stage2
  script:
    - echo "Can not be canceled."

step-3:
  stage: stage3
  script:
    - echo "Because step-2 can not be canceled, this step can never be canceled, even though it's set as interruptible."
  interruptible: true

이 예시에서 새 파이프라인은 실행 중인 파이프라인을 다음과 같이 처리합니다:

step-1만 실행 중이거나 대기 중인 경우 취소합니다.
step-2가 시작된 후에는 취소하지 않습니다.

auto_cancel:on_new_commit:interruptible 설정의 interruptible 예시:

workflow:
  auto_cancel:
    on_new_commit: interruptible

stages:
  - stage1
  - stage2
  - stage3

step-1:
  stage: stage1
  script:
    - echo "Can be canceled."
  interruptible: true

step-2:
  stage: stage2
  script:
    - echo "Can not be canceled."

step-3:
  stage: stage3
  script:
    - echo "Can be canceled."
  interruptible: true

이 예시에서 새 파이프라인은 step-1과 step-3이 실행 중이거나 대기 중인 경우 취소합니다.

추가 세부 정보:

빌드 job처럼 시작된 후에도 안전하게 취소할 수 있는 job에만 interruptible: true를 설정합니다. 배포 job은 부분 배포를 방지하기 위해 일반적으로 취소하면 안 됩니다.
기본 동작 또는 workflow:auto_cancel:on_new_commit: conservative를 사용하는 경우:
- 아직 시작되지 않은 job은 job 구성에 관계없이 항상 interruptible: true로 간주됩니다. interruptible 구성은 job이 시작된 후에만 고려됩니다.
- 실행 중인 파이프라인은 모든 실행 중인 job이 interruptible: true로 구성되어 있거나 어느 시점에도 interruptible: false로 구성된 job이 시작되지 않은 경우에만 취소됩니다. interruptible: false인 job이 시작되면 전체 파이프라인은 더 이상 중단 가능한 것으로 간주되지 않습니다.
- 파이프라인이 다운스트림 파이프라인을 트리거했지만 다운스트림 파이프라인에서 interruptible: false인 job이 아직 시작되지 않은 경우 다운스트림 파이프라인도 취소됩니다.
interruptible: false인 선택적 수동 job을 파이프라인의 첫 번째 stage에 추가하여 사용자가 파이프라인이 자동으로 취소되지 않도록 수동으로 방지할 수 있습니다. 사용자가 job을 시작하면 파이프라인은 중복 파이프라인 자동 취소 기능으로 취소할 수 없습니다.
trigger job과 함께 interruptible을 사용하는 경우:
- 트리거된 다운스트림 파이프라인은 trigger job의 interruptible 구성에 의해 절대 영향을 받지 않습니다.
- workflow:auto_cancel이 conservative로 설정된 경우 trigger job의 interruptible 구성은 효과가 없습니다.
- workflow:auto_cancel이 interruptible로 설정된 경우 interruptible: true인 trigger job은 자동으로 취소될 수 있습니다.

`needs`#

needs를 사용하여 순서 없이 job을 실행합니다. needs를 사용하는 job 간의 관계는 방향성 비순환 그래프로 시각화할 수 있습니다.

stage 순서를 무시하고 다른 job이 완료될 때까지 기다리지 않고 일부 job을 실행할 수 있습니다. 여러 stage의 job이 동시에 실행될 수 있습니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

job의 배열 (최대 50개 job).
빈 배열 ([]), job을 파이프라인이 생성되는 즉시 시작하도록 설정합니다.

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

이 예시는 네 가지 실행 경로를 생성합니다:

Linter: lint job은 needs: []로 인해 build stage가 완료될 때까지 기다리지 않고 즉시 실행됩니다.
Linux 경로: linux:rspec job은 linux:build job이 완료되는 즉시 실행되며 mac:build가 완료될 때까지 기다리지 않습니다.
macOS 경로: mac:rspec job은 mac:build job이 완료되는 즉시 실행되며 linux:build가 완료될 때까지 기다리지 않습니다.
production job은 이전의 모든 job이 완료되면 실행됩니다: lint, linux:build, linux:rspec, mac:build, mac:rspec.

추가 세부 정보:

단일 job이 needs 배열에 가질 수 있는 최대 job 수는 제한됩니다:
- GitLab.com의 경우 제한은 50입니다. 자세한 내용은 이슈 350398을 참조하세요.
- GitLab Self-Managed 및 GitLab Dedicated의 경우 기본 제한은 50입니다. 관리자 영역에서 CI/CD 제한을 업데이트하여 이 제한을 변경할 수 있습니다.
needs가 parallel 키워드를 사용하는 job을 참조하는 경우 하나의 job만이 아닌 병렬로 생성된 모든 job에 의존합니다. 또한 기본적으로 모든 병렬 job에서 아티팩트를 다운로드합니다. 아티팩트의 이름이 동일한 경우 서로 덮어쓰고 마지막으로 다운로드된 것만 저장됩니다.
- needs가 병렬화된 job의 하위 집합(전체가 아닌)을 참조하도록 하려면 needs:parallel:matrix 키워드를 사용하세요.
구성 중인 job과 동일한 stage의 job을 참조할 수 있습니다.
needs가 only, except, 또는 rules로 인해 파이프라인에 추가되지 않을 수 있는 job을 참조하는 경우 파이프라인 생성이 실패할 수 있습니다. needs:optional 키워드를 사용하여 파이프라인 생성 실패를 해결하세요.
파이프라인에 needs: []인 job과 .pre stage의 job이 있는 경우 파이프라인이 생성되는 즉시 모두 시작됩니다. needs: []인 job은 즉시 시작되고 .pre stage의 job도 즉시 시작됩니다.

`needs:artifacts`#

artifacts: true (기본값) 또는 artifacts: false를 사용하여 needs를 사용하는 job에서 아티팩트를 다운로드할 때를 제어합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다. 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 job은 build_job1 아티팩트를 다운로드합니다.
test-job2 job은 build_job2 아티팩트를 다운로드하지 않습니다.
test-job3 job은 세 가지 build_jobs의 아티팩트를 모두 다운로드합니다. 세 필요한 job 모두에서 artifacts가 true이거나 기본적으로 true이기 때문입니다.

추가 세부 정보:

동일한 job에서 needs와 dependencies를 함께 사용하지 않는 것이 좋습니다.

`needs:project`#

needs:project는 job, ref, artifacts와 함께 사용해야 합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

needs:project: 네임스페이스와 그룹을 포함한 전체 프로젝트 경로.
job: 아티팩트를 다운로드할 job.
ref: 아티팩트를 다운로드할 ref.
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

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

추가 세부 정보:

현재 프로젝트의 다른 파이프라인에서 아티팩트를 다운로드하려면 project를 현재 프로젝트와 동일하게 설정하되 현재 파이프라인과 다른 ref를 사용합니다. 동일한 ref에서 실행되는 동시 파이프라인이 아티팩트를 덮어쓸 수 있습니다.
파이프라인을 실행하는 사용자는 그룹 또는 프로젝트에 대한 Reporter, Developer, Maintainer, 또는 Owner 역할이 있어야 하거나 그룹/프로젝트가 공개 가시성이어야 합니다.
동일한 job에서 needs:project와 trigger를 사용할 수 없습니다.
다른 파이프라인에서 아티팩트를 다운로드하기 위해 needs:project를 사용하는 경우 job은 필요한 job이 완료될 때까지 기다리지 않습니다. needs를 사용하여 job이 완료될 때까지 기다리기는 동일한 파이프라인의 job으로 제한됩니다. 다른 파이프라인의 필요한 job이 아티팩트를 다운로드하려는 job보다 먼저 완료되는지 확인하세요.
parallel에서 실행되는 job에서 아티팩트를 다운로드할 수 없습니다.
project, job, ref에서 CI/CD 변수를 지원합니다.

관련 항목:

부모-자식 파이프라인 간에 아티팩트를 다운로드하려면 needs:pipeline:job을 사용하세요.

`needs:pipeline:job`#

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

needs:pipeline: 파이프라인 ID. 동일한 부모-자식 파이프라인 계층에 있는 파이프라인이어야 합니다.
job: 아티팩트를 다운로드할 job.

needs:pipeline:job 예시:

부모 파이프라인 (.gitlab-ci.yml):

stages:
  - build
  - test

create-artifact:
  stage: build
  script: echo "sample artifact" > artifact.txt
  artifacts:
    paths: [artifact.txt]

child-pipeline:
  stage: test
  trigger:
    include: child.yml
    strategy: mirror
  variables:
    PARENT_PIPELINE_ID: $CI_PIPELINE_ID

자식 파이프라인 (child.yml):

use-artifact:
  script: cat artifact.txt
  needs:
    - pipeline: $PARENT_PIPELINE_ID
      job: create-artifact

추가 세부 정보:

pipeline 속성은 현재 파이프라인 ID ($CI_PIPELINE_ID)를 허용하지 않습니다. 현재 파이프라인의 job에서 아티팩트를 다운로드하려면 needs:artifacts를 사용하세요.
trigger job에서 needs:pipeline:job을 사용하거나 멀티 프로젝트 파이프라인에서 아티팩트를 가져오는 데 사용할 수 없습니다. 멀티 프로젝트 파이프라인에서 아티팩트를 가져오려면 needs:project를 사용하세요.
needs:pipeline:job에 나열된 job은 success 상태로 완료되어야 아티팩트를 가져올 수 있습니다. 이슈 367229에서 아티팩트가 있는 모든 job에서 아티팩트를 가져올 수 있도록 허용할 것을 제안하고 있습니다.

`needs:optional`#

파이프라인에 때때로 존재하지 않는 job을 필요로 하려면 needs 구성에 optional: true를 추가합니다. 정의하지 않으면 optional: false가 기본값입니다.

needs 항목에 optional: true가 있고 필요한 job이 파이프라인에 있는 경우 job은 시작하기 전에 완료될 때까지 기다립니다.
필요한 job이 없는 경우 다른 모든 needs 요구 사항이 충족되면 job을 시작할 수 있습니다.
needs 섹션에 선택적 job만 있고 어느 것도 파이프라인에 추가되지 않은 경우 job은 즉시 시작됩니다 (빈 needs 항목: needs: []와 동일).
필요한 job에 optional: false가 있지만 파이프라인에 추가되지 않은 경우 파이프라인은 다음과 유사한 오류와 함께 시작에 실패합니다: 'job1' job needs 'job2' job, but it was not added to the pipeline.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

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는 stage 순서대로 시작됩니다.
브랜치가 기본 브랜치인 경우 test-job2가 파이프라인에 추가되므로:
- deploy-job은 test-job1과 test-job2가 모두 완료될 때까지 기다립니다.
- review-job은 test-job2가 완료될 때까지 기다립니다.
브랜치가 기본 브랜치가 아닌 경우 test-job2가 파이프라인에 추가되지 않으므로:
- deploy-job은 test-job1만 완료될 때까지 기다리고 누락된 test-job2를 기다리지 않습니다.
- review-job은 다른 필요한 job이 없어서 즉시 시작됩니다 (build-job과 동시에), needs: []와 같습니다.

추가 세부 정보:

needs:parallel:matrix와 함께 needs:optional을 사용할 수 없습니다.

`needs:pipeline`#

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

네임스페이스와 그룹을 포함한 전체 프로젝트 경로. 프로젝트가 동일한 그룹 또는 네임스페이스에 있는 경우 project 키워드에서 생략할 수 있습니다. 예: project: group/project-name 또는 project: project-name.

needs:pipeline 예시:

upstream_status:
  stage: test
  needs:
    pipeline: other/project

추가 세부 정보:

needs:pipeline에 job 키워드를 추가하면 job은 더 이상 파이프라인 상태를 미러링하지 않습니다. 동작이 needs:pipeline:job으로 변경됩니다.

`needs:parallel:matrix`#

히스토리

GitLab 16.3에서 도입되었습니다.

Job은 parallel:matrix를 사용하여 단일 파이프라인에서 여러 번 병렬로 실행할 수 있지만 job의 각 인스턴스마다 다른 변수 값을 사용합니다.

needs:parallel:matrix를 사용하여 병렬화된 job에 따라 순서 없이 job을 실행합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다. needs:job과 함께 사용해야 합니다.

지원되는 값: 매트릭스 식별자의 해시 배열:

식별자와 값은 parallel:matrix job에 정의된 식별자와 값에서 선택해야 합니다.
매트릭스 표현식을 사용할 수 있습니다.

needs:parallel:matrix 예시:

linux:build:
  stage: build
  script: echo "Building 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 "Running rspec on linux..."

이전 예시는 다음 job을 생성합니다:

linux:build: [aws, monitoring]
linux:build: [aws, app1]
linux:build: [aws, app2]
linux:rspec

linux:rspec job은 linux:build: [aws, app1] job이 완료되는 즉시 실행됩니다.

추가 세부 정보:

needs:optional과 함께 needs:parallel:matrix를 사용할 수 없습니다.

linux:rspec:
  stage: test
  needs:
    - job: linux:build
      parallel:
        matrix:
          - STACK: app1        # The variable order does not match `linux:build` and is invalid.
            PROVIDER: aws
  script: echo "Running rspec on linux..."

관련 항목:

`pages`#

pages를 사용하여 GitLab에 정적 콘텐츠를 업로드하는 GitLab Pages job을 정의합니다. 그러면 콘텐츠가 웹사이트로 게시됩니다.

다음을 수행해야 합니다:

pages: true를 정의하여 public이라는 디렉토리를 게시하거나
다른 콘텐츠 디렉토리를 사용하려면 pages.publish를 정의합니다.
콘텐츠 디렉토리의 루트에 비어 있지 않은 index.html 파일이 있어야 합니다.

키워드 유형: Job 키워드 또는 Job 이름(더 이상 사용되지 않음). job의 일부로만 사용할 수 있습니다.

지원되는 값:

불리언. true로 설정하면 기본 구성을 사용합니다.
구성 옵션의 해시, 자세한 내용은 다음 섹션을 참조하세요.

pages 예시:

create-pages:
  stage: deploy
  script:
    - mv my-html-content public
  pages: true  # specifies that this is a Pages job and publishes the default public directory
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  environment: production

이 예시는 my-html-content/ 디렉토리의 이름을 public/으로 변경합니다. 이 디렉토리는 아티팩트로 내보내지고 GitLab Pages로 게시됩니다.

구성 해시를 사용하는 예시:

create-pages:
  stage: deploy
  script:
    - echo "nothing to do here"
  pages:  # specifies that this is a Pages job and publishes the default public directory
    publish: my-html-content
    expire_in: "1 week"
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  environment: production

이 예시는 디렉토리를 이동하지 않고 publish 속성을 직접 사용합니다. 또한 일주일 후에 pages 배포가 게시 취소되도록 구성합니다.

추가 세부 정보:

pages를 job 이름으로 사용하는 것은 더 이상 사용되지 않습니다.
Pages 배포를 트리거하지 않고 pages를 job 이름으로 사용하려면 pages 속성을 false로 설정하세요.

`pages.publish`#

히스토리

GitLab 16.1에서 도입되었습니다.
GitLab 17.9에서 publish 속성에 변수를 전달할 때 허용하도록 변경되었습니다.
GitLab 17.9에서 publish 속성이 pages 키워드 아래로 이동되었습니다.
GitLab 17.10에서 pages.publish 경로가 artifacts:paths에 자동으로 추가되었습니다.

pages.publish를 사용하여 pages job의 콘텐츠 디렉토리를 구성합니다.

키워드 유형: Job 키워드. pages job의 일부로만 사용할 수 있습니다.

pages.publish 예시:

create-pages:
  stage: deploy
  script:
    - npx @11ty/eleventy --input=path/to/eleventy/root --output=dist
  pages:
    publish: dist  # this path is automatically appended to artifacts:paths
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  environment: production

pages.publish 필드에 변수를 사용할 수도 있습니다. 예시:

create-pages:
  stage: deploy
  script:
    - mkdir -p $CUSTOM_FOLDER/$CUSTOM_PATH
    - cp -r public $CUSTOM_FOLDER/$CUSTOM_SUBFOLDER
  pages:
    publish: $CUSTOM_FOLDER/$CUSTOM_SUBFOLDER  # this path is automatically appended to artifacts:paths
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  variables:
    CUSTOM_FOLDER: "custom_folder"
    CUSTOM_SUBFOLDER: "custom_subfolder"

지정된 publish 경로는 빌드 루트에 상대적이어야 합니다.

추가 세부 정보:

최상위 수준 publish 키워드는 더 이상 사용되지 않으며 이제 pages 키워드 아래에 중첩되어야 합니다.

`pages.path_prefix`#

히스토리

GitLab 16.7에서 pages_multiple_versions_setting이라는 플래그와 함께 실험으로 도입되었으며 기본적으로 비활성화되어 있습니다.
GitLab 17.4에서 GitLab.com, GitLab Self-Managed, GitLab Dedicated에서 활성화되었습니다.
GitLab 17.8에서 마침표를 허용하도록 변경되었습니다.
GitLab 17.9에서 일반 공개되었습니다. 기능 플래그 pages_multiple_versions_setting이 제거되었습니다.

pages.path_prefix를 사용하여 GitLab Pages의 병렬 배포에 대한 경로 접두사를 구성합니다.

키워드 유형: Job 키워드. pages job의 일부로만 사용할 수 있습니다.

지원되는 값:

문자열
CI/CD 변수
둘의 조합

pages.path_prefix 예시:

create-pages:
  stage: deploy
  script:
    - echo "Pages accessible through ${CI_PAGES_URL}"
  pages:  # specifies that this is a Pages job and publishes the default public directory
    path_prefix: "$CI_COMMIT_BRANCH"

이 예시에서 각 브랜치에 대해 다른 pages 배포가 생성됩니다.

`pages.expire_in`#

히스토리

GitLab 17.4에서 도입되었습니다.
변수 지원이 GitLab 17.11에서 도입되었습니다.

기본적으로 병렬 배포는 24시간 후에 자동으로 만료됩니다. 이 동작을 비활성화하려면 값을 never로 설정합니다.

키워드 유형: Job 키워드. pages job의 일부로만 사용할 수 있습니다.

지원되는 값: 만료 시간. 단위가 제공되지 않으면 시간은 초 단위입니다. 변수도 지원됩니다. 유효한 값은 다음을 포함합니다:

'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
$DURATION

pages.expire_in 예시:

create-pages:
  stage: deploy
  script:
    - echo "Pages accessible through ${CI_PAGES_URL}"
  pages:  # specifies that this is a Pages job and publishes the default public directory
    expire_in: 1 week

`parallel`#

히스토리

GitLab 15.9에서 parallel의 최대값이 50에서 200으로 증가했습니다 (도입).

parallel을 사용하여 단일 파이프라인에서 여러 번 병렬로 job을 실행합니다.

여러 러너가 있거나 단일 러너가 여러 job을 동시에 실행하도록 구성되어 있어야 합니다.

병렬 job은 job_name 1/N에서 job_name N/N까지 순차적으로 이름이 지정됩니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

1에서 200까지의 숫자 값.

parallel 예시:

test:
  script: rspec
  parallel: 5

이 예시는 test 1/5에서 test 5/5까지 이름이 지정된 5개의 job을 병렬로 생성합니다.

추가 세부 정보:

모든 병렬 job에는 CI_NODE_INDEX와 CI_NODE_TOTAL 사전 정의된 CI/CD 변수가 설정됩니다.
parallel을 사용하는 job이 있는 파이프라인은 다음과 같을 수 있습니다:
- 사용 가능한 러너보다 더 많은 job이 병렬로 생성될 수 있습니다. 초과 job은 대기열에 넣어지고 사용 가능한 러너를 기다리는 동안 pending으로 표시됩니다.
- 파이프라인을 생성하면 모든 활성 파이프라인의 총 job 수가 인스턴스 제한을 초과하게 되는 경우 job_activity_limit_exceeded 오류와 함께 실패할 수 있습니다.

관련 항목:

대규모 job 병렬화.

`parallel:matrix`#

히스토리

GitLab 15.9에서 최대 순열 수가 50에서 200으로 증가했습니다 (도입).

parallel:matrix를 사용하여 단일 파이프라인에서 여러 번 병렬로 job을 실행하되 job의 각 인스턴스마다 다른 변수 값을 사용합니다.

여러 러너가 있거나 단일 러너가 여러 job을 동시에 실행하도록 구성되어 있어야 합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값: 변수의 해시 배열:

변수 이름이 되는 매트릭스 식별자는 숫자, 문자, 밑줄 (_)만 사용할 수 있습니다.
값은 문자열이거나 문자열 배열이어야 합니다.
순열의 수는 200을 초과할 수 없습니다.

parallel:matrix 예시:

deploystacks:
  stage: deploy
  script:
    - bin/deploy
  parallel:
    matrix:
      - PROVIDER: aws
        STACK:
          - monitoring
          - app1
          - app2
      - PROVIDER: [gcp, vultr]
        STACK: [data, processing]
  environment: $PROVIDER/$STACK

이 예시는 PROVIDER와 STACK에 대해 다른 값을 가진 7개의 병렬 deploystacks job을 생성합니다:

deploystacks: [aws, monitoring]
deploystacks: [aws, app1]
deploystacks: [aws, app2]
deploystacks: [gcp, data]
deploystacks: [gcp, processing]
deploystacks: [vultr, data]
deploystacks: [vultr, processing]

추가 세부 정보:

parallel:matrix job은 서로를 구별하기 위해 job 이름에 매트릭스 값을 추가하지만 큰 값으로 인해 이름이 제한을 초과할 수 있습니다:
- Job 이름은 255자 이하여야 합니다.
- needs를 사용할 때 job 이름은 128자 이하여야 합니다.
매트릭스 값을 rules:if의 변수로 사용할 수 없습니다.
동일한 값이지만 이름이 다른 여러 매트릭스 구성을 생성할 수 없습니다. Job 이름은 이름이 아닌 매트릭스 값에서 생성되므로 동일한 값을 가진 매트릭스 항목은 서로 덮어쓰는 동일한 job 이름을 생성합니다.

예를 들어, 이 test 구성은 동일한 job의 두 시리즈를 생성하려 하지만 OS2 버전이 OS 버전을 덮어씁니다:
```
test:
  parallel:
    matrix:
      - OS: [ubuntu]
        PROVIDER: [aws, gcp]
      - OS2: [ubuntu]
        PROVIDER: [aws, gcp]
```

관련 항목:

`release`#

release를 사용하여 릴리스를 생성합니다.

release job은 $PATH에 있는 glab CLI에 액세스할 수 있어야 합니다.

Docker executor를 사용하는 경우 GitLab 컨테이너 레지스트리에서 이 이미지를 사용할 수 있습니다: registry.gitlab.com/gitlab-org/cli:latest

Shell executor 또는 유사한 executor를 사용하는 경우 러너가 등록된 서버에 glab CLI를 설치합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값: release 하위 키:

tag_name
tag_message (선택 사항)
name (선택 사항)
description
ref (선택 사항)
milestones (선택 사항)
released_at (선택 사항)
assets:links (선택 사항)

release 키워드 예시:

release_job:
  stage: release
  image: registry.gitlab.com/gitlab-org/cli:latest
  rules:
    - if: $CI_COMMIT_TAG                  # Run this job when a tag is created manually
  script:
    - echo "Running the release job."
  release:
    tag_name: $CI_COMMIT_TAG
    name: 'Release $CI_COMMIT_TAG'
    description: 'Release created using the CLI.'

이 예시는 다음 경우에 릴리스를 생성합니다:

Git 태그를 푸시할 때.
UI의 코드 > 태그에서 Git 태그를 추가할 때.

추가 세부 정보:

trigger job을 제외한 모든 release job은 script 키워드를 포함해야 합니다. release job은 script 명령의 출력을 사용할 수 있습니다. script가 필요하지 않은 경우 자리 표시자를 사용할 수 있습니다:
```
script:
  - echo "release job"
```
이 요구 사항을 제거하기 위한 이슈가 있습니다.
release 섹션은 script 키워드 이후와 after_script 이전에 실행됩니다.
릴리스는 job의 메인 스크립트가 성공한 경우에만 생성됩니다.
릴리스가 이미 존재하는 경우 업데이트되지 않으며 release 키워드가 있는 job이 실패합니다.

관련 항목:

`release:tag_name`#

필수. 릴리스의 Git 태그.

프로젝트에 태그가 아직 존재하지 않으면 릴리스와 동시에 생성됩니다. 새 태그는 파이프라인과 연결된 SHA를 사용합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

태그 이름.

CI/CD 변수는 지원됩니다.

release:tag_name 예시:

프로젝트에 새 태그가 추가될 때 릴리스를 생성하려면:

$CI_COMMIT_TAG CI/CD 변수를 tag_name으로 사용합니다.
rules:if를 사용하여 새 태그에 대해서만 job을 실행하도록 구성합니다.

job:
  script: echo "Running the release job for the new tag."
  release:
    tag_name: $CI_COMMIT_TAG
    description: 'Release description'
  rules:
    - if: $CI_COMMIT_TAG

릴리스와 새 태그를 동시에 생성하려면 rules에서 새 태그에 대해서만 job을 실행하도록 구성하지 않아야 합니다. 시맨틱 버저닝 예시:

job:
  script: echo "Running the release job and creating a new tag."
  release:
    tag_name: ${MAJOR}_${MINOR}_${REVISION}
    description: 'Release description'
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"

`release:tag_message`#

태그가 존재하지 않으면 새로 생성된 태그에 tag_message로 지정된 메시지가 주석으로 추가됩니다. 생략하면 경량 태그가 생성됩니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

텍스트 문자열.

release:tag_message 예시:

  release_job:
    stage: release
    release:
      tag_name: $CI_COMMIT_TAG
      description: 'Release description'
      tag_message: 'Annotated tag message'

`release:name`#

릴리스 이름. 생략하면 release: tag_name 값으로 채워집니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

텍스트 문자열.

release:name 예시:

  release_job:
    stage: release
    release:
      name: 'Release $CI_COMMIT_TAG'

`release:description`#

릴리스의 긴 설명.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

긴 설명이 있는 문자열.
설명이 포함된 파일 경로.
- 파일 위치는 프로젝트 디렉토리 ($CI_PROJECT_DIR)에 상대적이어야 합니다.
- 파일이 심볼릭 링크인 경우 $CI_PROJECT_DIR에 있어야 합니다.
- ./path/to/file과 파일 이름에는 공백이 포함될 수 없습니다.

release:description 예시:

job:
  release:
    tag_name: ${MAJOR}_${MINOR}_${REVISION}
    description: './path/to/CHANGELOG.md'

추가 세부 정보:

description은 glab을 실행하는 쉘에 의해 평가됩니다. CI/CD 변수를 사용하여 설명을 정의할 수 있지만 일부 쉘은 다른 구문을 사용으로 변수를 참조합니다. 마찬가지로 일부 쉘은 특수 문자를 이스케이프해야 할 수 있습니다. 예를 들어 백틱 (`)은 백슬래시 (\)로 이스케이프해야 할 수 있습니다.

`release:ref`#

release: tag_name이 아직 존재하지 않는 경우 릴리스의 ref.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

커밋 SHA, 다른 태그 이름, 또는 브랜치 이름.

`release:milestones`#

릴리스와 연결된 각 마일스톤의 제목.

`release:released_at`#

릴리스가 준비된 날짜와 시간.

지원되는 값:

따옴표로 묶인 날짜, ISO 8601 형식으로 표현.

release:released_at 예시:

released_at: '2021-03-15T08:00:00Z'

추가 세부 정보:

정의하지 않으면 현재 날짜와 시간이 사용됩니다.

`release:assets:links`#

release:assets:links를 사용하여 릴리스에 자산 링크를 포함합니다.

release:assets:links 예시:

assets:
  links:
    - name: 'asset1'
      url: 'https://example.com/assets/1'
    - name: 'asset2'
      url: 'https://example.com/assets/2'
      filepath: '/pretty/url/1' # optional
      link_type: 'other' # optional

`resource_group`#

resource_group을 사용하여 동일한 프로젝트의 다른 파이프라인에서 job이 상호 배타적임을 보장하는 리소스 그룹을 생성합니다.

리소스 그룹은 다른 프로그래밍 언어의 세마포어와 유사하게 동작합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

문자, 숫자, -, _, /, $, {, }, ., 공백만 허용됩니다. /로 시작하거나 끝날 수 없습니다. CI/CD 변수는 지원됩니다.

resource_group 예시:

deploy-to-production:
  script: deploy
  resource_group: production

관련 항목:

크로스 프로젝트/부모-자식 파이프라인을 통한 파이프라인 수준의 동시성 제어.

`retry`#

retry를 사용하여 job이 실패한 경우 재시도 횟수를 구성합니다. 정의하지 않으면 기본값은 0이며 job은 재시도하지 않습니다.

job이 실패하면 성공하거나 최대 재시도 횟수에 도달할 때까지 최대 두 번 더 처리됩니다.

기본적으로 모든 실패 유형으로 인해 job이 재시도됩니다. retry:when 또는 retry:exit_codes를 사용하여 재시도할 실패를 선택합니다.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

0 (기본값), 1, 또는 2.

retry 예시:

test:
  script: rspec
  retry: 2

test_advanced:
  script:
    - echo "Run a script that results in exit code 137."
    - exit 137
  retry:
    max: 2
    when: runner_system_failure
    exit_codes: 137

test_advanced는 종료 코드가 137이거나 러너 시스템 실패가 있는 경우 최대 2번 재시도됩니다.

`retry:when`#

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

단일 실패 유형 또는 하나 이상의 실패 유형 배열:
always: 모든 실패에 대해 재시도 (기본값).
unknown_failure: 실패 이유를 알 수 없을 때 재시도.
script_failure: 다음 경우에 재시도:
- 스크립트가 실패했을 때.
- 러너가 Docker 이미지를 가져오지 못했을 때. docker, docker+machine, kubernetes executor 의 경우.
api_failure: API 실패 시 재시도.
stuck_or_timeout_failure: job이 멈추거나 시간 초과될 때 재시도.
runner_system_failure: 러너 시스템 실패가 있는 경우 재시도 (예: job 설정 실패).
runner_unsupported: 러너가 지원되지 않는 경우 재시도.
stale_schedule: 지연된 job을 실행할 수 없는 경우 재시도.
job_execution_timeout: 스크립트가 job에 설정된 최대 실행 시간을 초과한 경우 재시도.
archived_failure: job이 아카이브되어 실행할 수 없는 경우 재시도.
unmet_prerequisites: job이 사전 조건 작업을 완료하지 못한 경우 재시도.
scheduler_failure: 스케줄러가 job을 러너에 할당하지 못한 경우 재시도.
data_integrity_failure: 알 수 없는 job 문제가 있는 경우 재시도.

retry:when 예시 (단일 실패 유형):

test:
  script: rspec
  retry:
    max: 2
    when: runner_system_failure

러너 시스템 실패 외의 다른 실패가 있는 경우 job은 재시도되지 않습니다.

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 16.11에서 GitLab.com 및 GitLab Self-Managed에서 활성화되었습니다.
GitLab 17.5에서 일반 공개되었습니다. 기능 플래그 ci_retry_on_exit_codes가 제거되었습니다.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

단일 종료 코드.
종료 코드 배열.

retry:exit_codes 예시:

test_job_1:
  script:
    - echo "Run a script that results in exit code 1. This job isn't retried."
    - exit 1
  retry:
    max: 2
    exit_codes: 137

test_job_2:
  script:
    - echo "Run a script that results in exit code 137. This job will be retried."
    - exit 137
  retry:
    max: 1
    exit_codes:
      - 255
      - 137

관련 항목:

변수를 사용하여 job 실행의 특정 단계에 대한 재시도 횟수를 지정할 수 있습니다.

`rules`#

rules를 사용하여 파이프라인에서 job을 포함하거나 제외합니다.

rules는 규칙 배열을 허용합니다. 각 규칙에는 다음 중 하나 이상이 있어야 합니다:

if
changes
exists
when

규칙은 선택적으로 다음과 함께 결합될 수도 있습니다:

allow_failure
needs
variables
interruptible

복잡한 규칙을 위해 여러 키워드를 함께 결합할 수 있습니다.

job이 파이프라인에 추가되는 경우:

if, changes, 또는 exists 규칙이 일치하고 when: on_success (정의하지 않으면 기본값), when: delayed, 또는 when: always로 구성된 경우.
when: on_success, when: delayed, 또는 when: always만 있는 규칙에 도달한 경우.

job이 파이프라인에 추가되지 않는 경우:

어떤 규칙도 일치하지 않는 경우.
규칙이 일치하고 when: never인 경우.

추가 예시는 rules로 job이 실행되는 시기 지정을 참조하세요.

`rules:if`#

rules:if 절을 사용하여 파이프라인에 job을 추가하는 시기를 지정합니다:

if 문이 true이면 파이프라인에 job을 추가합니다.
if 문이 true이지만 when: never와 결합된 경우 파이프라인에 job을 추가하지 않습니다.
if 문이 false이면 다음 rules 항목을 확인합니다 (더 있는 경우).

if 절은 다음을 기반으로 평가됩니다:

일부 예외 사항이 있는 CI/CD 변수 또는 사전 정의된 CI/CD 변수의 값.
rules 실행 흐름을 따르는 순서.

지원되는 값:

CI/CD 변수 표현식.

rules:if 예시:

job:
  script: echo "Hello, 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

추가 세부 정보:

if와 함께 중첩 변수를 사용할 수 없습니다. 자세한 내용은 이슈 327780을 참조하세요.
규칙이 일치하고 when이 정의되지 않은 경우 규칙은 job에 정의된 when을 사용하며 정의되지 않은 경우 기본값은 on_success입니다.
when을 job 수준에서 rules의 when과 혼합할 수 있습니다. rules의 when 구성이 job 수준의 when보다 우선합니다.
script 섹션의 변수와 달리 rules 표현식의 변수는 항상 $VARIABLE 형식입니다.
- include와 함께 rules:if를 사용하여 다른 구성 파일을 조건부로 포함할 수 있습니다.
=~ 및 !~ 표현식의 오른쪽에 있는 CI/CD 변수는 정규 표현식으로 평가됩니다.

관련 항목:

`rules:changes`#

rules:changes를 사용하여 특정 파일의 변경 사항을 확인하여 파이프라인에 job을 추가하는 시기를 지정합니다.

머지 리퀘스트 파이프라인의 경우 rules:changes는 대상 MR 브랜치와 변경 사항을 비교합니다.
브랜치 파이프라인의 경우 rules:changes는 브랜치의 이전 커밋과 변경 사항을 비교합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

다음을 포함하는 배열:

파일 경로. 파일 경로는 CI/CD 변수를 포함할 수 있습니다.
와일드카드 경로:
- 단일 디렉토리의 경우, 예: 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

docker build alternative:
  variables:
    DOCKERFILES_DIR: 'path/to/dockerfiles'
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      changes:
        - $DOCKERFILES_DIR/**/*

이 예시에서:

파이프라인이 머지 리퀘스트 파이프라인이면 Dockerfile과 $DOCKERFILES_DIR/**/*의 파일 변경 사항을 확인합니다.
Dockerfile이 변경되었으면 job을 수동 job으로 파이프라인에 추가하고 job이 트리거되지 않아도 파이프라인이 계속 실행됩니다 (allow_failure: true).
$DOCKERFILES_DIR/**/*의 파일이 변경되었으면 파이프라인에 job을 추가합니다.
나열된 파일이 변경되지 않았으면 어떤 파이프라인에도 어떤 job도 추가하지 않습니다 (when: never와 동일).

추가 세부 정보:

Glob 패턴은 Ruby의 File.fnmatch로 플래그 File::FNM_PATHNAME | File::FNM_DOTMATCH | File::FNM_EXTGLOB을 사용하여 해석됩니다.
성능상의 이유로 GitLab은 changes 패턴 또는 파일 경로에 대해 최대 50,000번의 검사를 수행합니다. 50,000번째 검사 이후에는 패턴화된 glob이 있는 규칙이 항상 일치합니다. 즉, 50,000개 이상의 파일이 변경되었거나 변경된 파일이 50,000개 미만이지만 changes 규칙이 50,000번 이상 확인된 경우 changes 규칙은 항상 일치한다고 가정합니다.
rules:changes 섹션당 최대 50개의 패턴 또는 파일 경로를 정의할 수 있습니다.
changes는 나열된 파일 중 하나라도 변경된 경우 true로 확인됩니다 (OR 연산).
추가 예시는 rules로 job이 실행되는 시기 지정을 참조하세요.
변수와 경로 모두에 $ 문자를 사용할 수 있습니다. 예를 들어 $VAR 변수가 존재하면 그 값이 사용됩니다. 존재하지 않으면 $는 경로의 일부로 해석됩니다.
./, 이중 슬래시 (//) 또는 다른 종류의 상대 경로를 사용하지 마세요. 경로는 정확한 문자열 비교로 일치하며 쉘에서처럼 평가되지 않습니다.

관련 항목:

rules: changes 사용 시 job 또는 파이프라인이 예기치 않게 실행됨.

`rules:changes:paths`#

히스토리

GitLab 15.2에서 도입되었습니다.

rules:changes를 사용하여 특정 파일이 변경된 경우에만 파이프라인에 job을 추가하고 rules:changes:paths를 사용하여 파일을 지정합니다.

rules:changes:paths는 하위 키 없이 rules:changes를 사용하는 것과 동일합니다. 모든 추가 세부 정보 및 관련 항목은 동일합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

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

이 예시에서 두 job의 동작은 동일합니다.

`rules:changes:compare_to`#

히스토리

GitLab 15.3에서 ci_rules_changes_compare라는 플래그와 함께 도입되었습니다. 기본적으로 활성화되어 있습니다.
GitLab 15.5에서 일반 공개되었습니다. 기능 플래그 ci_rules_changes_compare가 제거되었습니다.
CI/CD 변수 지원이 GitLab 17.2에서 도입되었습니다.

rules:changes:compare_to를 사용하여 rules:changes:paths 아래에 나열된 파일의 변경 사항과 비교할 ref를 지정합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있으며 rules:changes:paths와 함께 사용해야 합니다.

지원되는 값:

main, branch1, 또는 refs/heads/branch1과 같은 브랜치 이름.
tag1 또는 refs/tags/tag1과 같은 태그 이름.
2fg31ga14b와 같은 커밋 SHA.

CI/CD 변수는 지원됩니다.

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 job은 Dockerfile이 refs/heads/branch1에 상대적으로 변경되었고 파이프라인 소스가 머지 리퀘스트 이벤트인 경우에만 포함됩니다.

추가 세부 정보:

일부 상황에서 compare_to를 사용하면 예상치 못한 결과가 발생할 수 있습니다:
- 병합 결과 파이프라인에서는 비교 기반이 GitLab이 생성하는 내부 커밋이기 때문입니다.
- 포크된 프로젝트에서는 이슈 424584를 참조하세요.

관련 항목:

rules:changes:compare_to를 사용하여 브랜치가 비어 있는 경우 job 건너뛰기.

`rules:exists`#

히스토리

CI/CD 변수 지원이 GitLab 15.6에서 도입되었습니다.
exists 패턴 또는 파일 경로에 대한 최대 검사 수가 GitLab 17.7에서 10,000에서 50,000으로 증가했습니다.
디렉토리 경로 지원이 GitLab 18.2에서 도입되었습니다.

리포지터리에 특정 파일 또는 디렉토리가 존재할 때 job을 실행하려면 exists를 사용합니다.

키워드 유형: Job 키워드. job의 일부 또는 include에서 사용할 수 있습니다.

지원되는 값:

파일 또는 디렉토리 경로의 배열. 경로는 프로젝트 디렉토리 ($CI_PROJECT_DIR)에 상대적이며 외부로 직접 연결할 수 없습니다. 파일 경로는 glob 패턴과 CI/CD 변수를 사용할 수 있습니다.

rules:exists 예시:

job1:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - exists:
        - Dockerfile

job2:
  variables:
    DOCKERPATH: "**/Dockerfile"
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - exists:
        - $DOCKERPATH

이 예시에서:

job1은 리포지터리의 루트 디렉토리에 Dockerfile이 존재하면 실행됩니다.
job2는 리포지터리 어디에나 Dockerfile이 존재하면 실행됩니다.

추가 세부 정보:

Glob 패턴은 Ruby의 File.fnmatch로 플래그 File::FNM_PATHNAME | File::FNM_DOTMATCH | File::FNM_EXTGLOB을 사용하여 해석됩니다.
성능상의 이유로 GitLab은 exists 패턴 또는 파일 경로에 대해 최대 50,000번의 검사를 수행합니다. 50,000번째 검사 이후에는 패턴화된 glob이 있는 규칙이 항상 일치합니다. 즉, 파일이 50,000개 이상인 프로젝트나 파일이 50,000개 미만이지만 exists 규칙이 50,000번 이상 확인된 경우 exists 규칙은 항상 일치한다고 가정합니다.
- 여러 패턴화된 glob이 있는 경우 제한은 50,000을 glob의 수로 나눈 값입니다. 예를 들어 5개의 패턴화된 glob이 있는 규칙은 파일 제한이 10,000입니다.
rules:exists 섹션당 최대 50개의 패턴 또는 파일 경로를 정의할 수 있습니다.
exists는 나열된 파일 중 하나라도 발견되면 true로 확인됩니다 (OR 연산).
job 수준 rules:exists에서 GitLab은 파이프라인을 실행하는 프로젝트 및 ref에서 파일을 검색합니다. include와 함께 rules:exists 사용 시 GitLab은 include 섹션이 포함된 파일의 프로젝트 및 ref에서 파일 또는 디렉토리를 검색합니다. include 섹션이 포함된 프로젝트는 다음을 사용할 때 파이프라인을 실행하는 프로젝트와 다를 수 있습니다:
- 중첩 포함.
- 컴플라이언스 파이프라인.
rules:exists는 아티팩트의 존재를 검색할 수 없습니다. rules 평가는 job이 실행되고 아티팩트가 가져와지기 전에 발생하기 때문입니다.
디렉토리의 존재를 테스트하려면 경로가 슬래시 (/)로 끝나야 합니다.

`rules:exists:paths`#

히스토리

GitLab 16.11에서 ci_support_rules_exists_paths_and_project라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
GitLab 17.0에서 일반 공개되었습니다. 기능 플래그 ci_support_rules_exists_paths_and_project가 제거되었습니다.

rules:exists:paths는 하위 키 없이 rules:exists를 사용하는 것과 동일합니다. 모든 추가 세부 정보는 동일합니다.

키워드 유형: Job 키워드. job의 일부 또는 include에서 사용할 수 있습니다.

지원되는 값:

파일 경로 배열.

rules:exists:paths 예시:

docker-build-1:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      exists:
        - Dockerfile

docker-build-2:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      exists:
        paths:
          - Dockerfile

이 예시에서 두 job의 동작은 동일합니다.

`rules:exists:project`#

히스토리

GitLab 16.11에서 ci_support_rules_exists_paths_and_project라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
GitLab 17.0에서 일반 공개되었습니다. 기능 플래그 ci_support_rules_exists_paths_and_project가 제거되었습니다.

rules:exists:project를 사용하여 rules:exists:paths 아래에 나열된 파일을 검색할 위치를 지정합니다. rules:exists:paths와 함께 사용해야 합니다.

키워드 유형: Job 키워드. job의 일부 또는 include에서 사용할 수 있으며 rules:exists:paths와 함께 사용해야 합니다.

지원되는 값:

exists:project: 네임스페이스와 그룹을 포함한 전체 프로젝트 경로.
exists:ref: 선택 사항. 파일을 검색하는 데 사용할 커밋 ref. ref는 태그, 브랜치 이름, 또는 SHA일 수 있습니다. 지정하지 않으면 프로젝트의 HEAD로 기본 설정됩니다.

rules:exists:project 예시:

docker build:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - exists:
        paths:
          - Dockerfile
        project: my-group/my-project
        ref: v1.0.0

이 예시에서 docker build job은 Dockerfile이 v1.0.0 태그에 커밋된 my-group/my-project 프로젝트에 존재할 때만 포함됩니다.

`rules:when`#

rules:when 규칙이 if, changes, 또는 exists와 결합되지 않은 경우 job의 규칙을 평가할 때 도달하면 항상 일치합니다.

키워드 유형: job별. job의 일부로만 사용할 수 있습니다.

지원되는 값:

on_success (기본값): 이전 stage의 job이 실패하지 않는 경우에만 job을 실행합니다.
on_failure: 이전 stage에서 하나 이상의 job이 실패한 경우에만 job을 실행합니다.
never: 이전 stage의 job 상태에 관계없이 job을 실행하지 않습니다.
always: 이전 stage의 job 상태에 관계없이 job을 실행합니다.
manual: job을 수동 job으로 파이프라인에 추가합니다. allow_failure의 기본값이 false로 변경됩니다.
delayed: job을 지연 job으로 파이프라인에 추가합니다.

rules:when 예시:

job1:
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
    - if: $CI_COMMIT_REF_NAME =~ /feature/
      when: delayed
    - when: manual
  script:
    - echo

이 예시에서 job1은 다음 파이프라인에 추가됩니다:

기본 브랜치의 경우 when이 정의되지 않을 때의 기본 동작인 when: on_success를 사용합니다.
feature 브랜치의 경우 지연 job으로.
다른 모든 경우에는 수동 job으로.

추가 세부 정보:

on_success 및 on_failure에 대한 job 상태를 평가할 때:
- 이전 stage에서 allow_failure: true가 있는 job은 실패했더라도 성공한 것으로 간주됩니다.
- 이전 stage에서 건너뛴 job, 예를 들어 시작되지 않은 수동 job은 성공한 것으로 간주됩니다.
rules:when: manual을 사용하여 수동 job을 추가할 때:
- allow_failure는 기본적으로 false가 됩니다. 이 기본값은 수동 job을 추가하기 위해 when: manual을 사용하는 것과 반대입니다.
- rules 외부에서 정의된 when: manual과 동일한 동작을 달성하려면 rules: allow_failure를 true로 설정합니다.

`rules:allow_failure`#

rules에서 allow_failure: true를 사용하여 파이프라인을 중지하지 않고 job이 실패하도록 허용합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

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

규칙이 일치하면 job은 allow_failure: true가 있는 수동 job입니다.

추가 세부 정보:

규칙 수준의 rules:allow_failure는 job 수준의 allow_failure를 재정의하며 특정 규칙이 job을 트리거할 때만 적용됩니다.

`rules:needs`#

히스토리

GitLab 16.0에서 introduce_rules_with_needs라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
GitLab 16.2에서 일반 공개되었습니다. 기능 플래그 introduce_rules_with_needs가 제거되었습니다.

키워드 유형: job별. job의 일부로만 사용할 수 있습니다.

지원되는 값:

문자열로 된 job 이름 배열.
추가 속성이 있는 job 이름의 해시 (선택 사항).
빈 배열 ([]), 특정 조건이 충족될 때 job needs를 없음으로 설정합니다.

rules:needs 예시:

build-dev:
  stage: build
  rules:
    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH
  script: echo "Feature branch, so building dev version..."

build-prod:
  stage: build
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  script: echo "Default branch, so building prod version..."

tests:
  stage: test
  rules:
    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH
      needs: ['build-dev']
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      needs: ['build-prod']
  script: echo "Running dev specs by default, or prod specs when default branch..."

이 예시에서:

파이프라인이 기본 브랜치가 아닌 브랜치에서 실행되어 첫 번째 조건과 규칙이 일치하면 specs job은 build-dev job이 필요합니다.
파이프라인이 기본 브랜치에서 실행되어 두 번째 조건과 규칙이 일치하면 specs job은 build-prod job이 필요합니다.

추가 세부 정보:

rules의 needs는 job 수준에서 정의된 needs를 재정의합니다. 재정의 시 동작은 job 수준 needs와 동일합니다.
rules의 needs는 artifacts 및 optional을 허용할 수 있습니다.

`rules:variables`#

rules에서 variables를 사용하여 특정 조건에 대한 변수를 정의합니다.

키워드 유형: job별. job의 일부로만 사용할 수 있습니다.

지원되는 값:

VARIABLE-NAME: value 형식의 변수 해시.

rules:variables 예시:

job:
  variables:
    DEPLOY_VARIABLE: "default-deploy"
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      variables:                              # Override DEPLOY_VARIABLE defined
        DEPLOY_VARIABLE: "deploy-production"  # at the job level.
    - if: $CI_COMMIT_REF_NAME =~ /feature/
      variables:
        IS_A_FEATURE: "true"                  # Define a new variable.
  script:
    - echo "Run script with $DEPLOY_VARIABLE as an argument"
    - echo "Run another script if $IS_A_FEATURE exists"

`rules:interruptible`#

히스토리

GitLab 16.10에서 도입되었습니다.

rules에서 interruptible을 사용하여 특정 조건에 대한 job의 interruptible 값을 업데이트합니다.

키워드 유형: job별. job의 일부로만 사용할 수 있습니다.

지원되는 값:

true 또는 false.

rules:interruptible 예시:

job:
  script: echo "Hello, Rules!"
  interruptible: true
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      interruptible: false  # Override interruptible defined at the job level.
    - when: on_success

추가 세부 정보:

규칙 수준의 rules:interruptible은 job 수준의 interruptible을 재정의하며 특정 규칙이 job을 트리거할 때만 적용됩니다.

`run`#

히스토리

GitLab 17.3에서 pipeline_run_keyword라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다. GitLab Runner 17.1이 필요합니다.
기능 플래그 pipeline_run_keyword가 GitLab 17.5에서 제거되었습니다.

Note

이 기능은 테스트에 사용할 수 있지만 프로덕션 사용에는 준비되지 않았습니다.

run을 사용하여 job에서 실행할 일련의 steps를 정의합니다. 각 step은 스크립트 또는 사전 정의된 step일 수 있습니다.

선택적 환경 변수와 입력값을 제공할 수도 있습니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

해시 배열, 각 해시는 다음 가능한 키가 있는 step을 나타냅니다:
- name: step의 이름을 나타내는 문자열.
- script: 실행할 쉘 명령이 포함된 문자열.
- step: 실행할 사전 정의된 step을 식별하는 문자열.
- env: 선택 사항. 이 step에 특정한 환경 변수의 해시.
- inputs: 선택 사항. 사전 정의된 step의 입력 파라미터 해시.

각 배열 항목에는 name과 script 또는 step 중 하나 (둘 다는 안 됨)가 있어야 합니다.

run 예시:

job:
  run:
    - name: 'hello_steps'
      script: 'echo "hello from step1"'
    - name: 'bye_steps'
      step: gitlab.com/gitlab-org/ci-cd/runner-tools/echo-step@main
      inputs:
        echo: 'bye steps!'
      env:
        var1: 'value 1'

이 예시에서 job에는 두 가지 step이 있습니다:

hello_steps는 echo 쉘 명령을 실행합니다.
bye_steps는 환경 변수와 입력 파라미터가 있는 사전 정의된 step을 사용합니다.

추가 세부 정보:

step에는 script 또는 step 키 중 하나만 있을 수 있으며 둘 다는 안 됩니다.
run 구성은 기존 script, after_script 또는 before_script 키워드와 함께 사용할 수 없습니다.
여러 줄 스크립트는 YAML 블록 스칼라 구문을 사용하여 정의할 수 있습니다.

`script`#

script를 사용하여 러너가 실행할 명령을 지정합니다.

trigger job을 제외한 모든 job에는 script 키워드가 필요합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값: 다음을 포함하는 배열:

단일 줄 명령.
여러 줄로 분할된 긴 명령.
YAML 앵커.

CI/CD 변수는 지원됩니다.

script 예시:

job1:
  script: "bundle exec rspec"

job2:
  script:
    - uname -a
    - bundle exec rspec

추가 세부 정보:

script에서 이러한 특수 문자를 사용할 때는 작은따옴표 (') 또는 큰따옴표 (")를 사용해야 합니다.

관련 항목:

0이 아닌 종료 코드를 무시할 수 있습니다.
작업 로그를 더 쉽게 검토할 수 있도록 script에 색상 코드를 사용합니다.
작업 로그 출력을 단순화하기 위해 사용자 정의 축소 가능한 섹션을 생성합니다.

`secrets`#

secrets를 사용하여 다음을 위한 CI/CD 시크릿을 지정합니다:

외부 시크릿 제공자에서 가져오기.
job에서 CI/CD 변수로 사용 가능하게 하기 (기본적으로 file 유형).

`secrets:vault`#

히스토리

generic 엔진 옵션이 GitLab Runner 16.11에서 도입되었습니다.

secrets:vault를 사용하여 HashiCorp Vault에서 제공하는 시크릿을 지정합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

engine:name: 시크릿 엔진의 이름. kv-v2 (기본값), kv-v1, 또는 generic 중 하나일 수 있습니다.
engine:path: 시크릿 엔진의 경로.
path: 시크릿의 경로.
field: 비밀번호가 저장된 필드 이름.

secrets:vault 예시:

모든 세부 정보를 명시적으로 지정하고 KV-V2 시크릿 엔진을 사용하려면:

job:
  secrets:
    DATABASE_PASSWORD:  # Store the path to the secret in this CI/CD variable
      vault:  # Translates to secret: `ops/data/production/db`, field: `password`
        engine:
          name: kv-v2
          path: ops
        path: production/db
        field: password

이 구문을 단축할 수 있습니다. 단축 구문을 사용하면 engine:name과 engine:path가 모두 kv-v2로 기본 설정됩니다:

job:
  secrets:
    DATABASE_PASSWORD:  # Store the path to the secret in this CI/CD variable
      vault: production/db/password  # Translates to secret: `kv-v2/data/production/db`, field: `password`

단축 구문에서 사용자 정의 시크릿 엔진 경로를 지정하려면 @로 시작하는 접미사를 추가합니다:

job:
  secrets:
    DATABASE_PASSWORD:  # Store the path to the secret in this CI/CD variable
      vault: production/db/password@ops  # Translates to secret: `ops/data/production/db`, field: `password`

`secrets:gcp_secret_manager`#

히스토리

GitLab 16.8 및 GitLab Runner 16.8에서 도입되었습니다.

secrets:gcp_secret_manager를 사용하여 GCP Secret Manager에서 제공하는 시크릿을 지정합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

name: 시크릿의 이름.
version: 시크릿의 버전.

secrets:gcp_secret_manager 예시:

job:
  secrets:
    DATABASE_PASSWORD:
      gcp_secret_manager:
        name: 'test'
        version: 2

관련 항목:

GitLab CI/CD에서 GCP Secret Manager 시크릿 사용.

`secrets:azure_key_vault`#

히스토리

GitLab 16.3 및 GitLab Runner 16.3에서 도입되었습니다.

secrets:azure_key_vault를 사용하여 Azure Key Vault에서 제공하는 시크릿을 지정합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

name: 시크릿의 이름.
version: 시크릿의 버전.

secrets:azure_key_vault 예시:

job:
  secrets:
    DATABASE_PASSWORD:
      azure_key_vault:
        name: 'test'
        version: 'test'

관련 항목:

GitLab CI/CD에서 Azure Key Vault 시크릿 사용.

`secrets:file`#

secrets:file을 사용하여 시크릿을 file 또는 variable 유형 CI/CD 변수로 저장할지 구성합니다.

기본적으로 시크릿은 job에 file 유형 CI/CD 변수로 전달됩니다. 시크릿의 값은 파일에 저장되고 변수에는 파일 경로가 포함됩니다.

소프트웨어가 file 유형 CI/CD 변수를 사용할 수 없는 경우 시크릿 값을 변수에 직접 저장하려면 file: false를 설정합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값:

true (기본값) 또는 false.

secrets:file 예시:

job:
  secrets:
    DATABASE_PASSWORD:
      vault: production/db/password@ops
      file: false

추가 세부 정보:

file 키워드는 CI/CD 변수의 설정이며 vault 섹션이 아닌 CI/CD 변수 이름 아래에 중첩되어야 합니다.

`secrets:token`#

히스토리

JSON Web Token (JWT) 액세스 제한 설정에 의해 제어되는 GitLab 15.8에서 도입되었습니다.
GitLab 16.0에서 항상 사용 가능하게 되었으며 JSON Web Token (JWT) 액세스 제한 설정이 제거되었습니다.

secrets:token을 사용하여 토큰의 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 키워드가 설정되지 않았고 토큰이 하나만 정의된 경우 정의된 토큰이 자동으로 사용됩니다.
토큰이 두 개 이상 정의된 경우 token 키워드를 설정하여 사용할 토큰을 지정해야 합니다. 사용할 토큰을 지정하지 않으면 job이 실행될 때마다 어떤 토큰이 사용되는지 예측할 수 없습니다.

`services`#

Warning

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값: 필요한 경우 레지스트리 경로를 포함한 서비스 이미지 이름, 다음 형식 중 하나로:

<image-name> (latest 태그와 함께 <image-name> 사용과 동일)
<image-name>:<tag>
<image-name>@<digest>

CI/CD 변수는 지원됩니다, 단 alias에는 지원되지 않습니다. alias를 동적으로 사용자 정의하려면 CI/CD 입력값을 대신 사용하세요.

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은 job에 대한 두 컨테이너를 시작합니다:

스크립트 명령을 실행하는 Ruby 컨테이너.
PostgreSQL 컨테이너. Ruby 컨테이너의 스크립트 명령은 db-postgres 호스트 이름에서 PostgreSQL 데이터베이스에 연결할 수 있습니다.

추가 세부 정보:

default 섹션이 아닌 최상위 수준에서 services를 사용하는 것은 더 이상 사용되지 않습니다.

관련 항목:

`services:name`#

서비스에 사용할 이미지의 전체 이름.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값: 필요한 경우 레지스트리 경로를 포함한 서비스 이미지 이름, 다음 형식 중 하나로:

<image-name> (latest 태그와 함께 <image-name> 사용과 동일)
<image-name>:<tag>
<image-name>@<digest>

CI/CD 변수는 지원됩니다.

services:name 예시:

services:
  - name: postgres:11.7
  - name: registry.example.com/my-org/custom-service:latest

추가 세부 정보:

여러 동일한 서비스 이미지를 사용하거나 서비스 이미지 이름이 긴 경우 고유한 이름 별칭을 정의하려면 alias를 사용합니다.
entrypoint, command 또는 variables와 같은 다른 서비스 옵션과 함께 사용할 때 name 키워드가 필요합니다.
자세한 내용은 서비스에 액세스하기를 참조하세요.

`services:alias`#

히스토리

GitLab Runner 17.9에서 도입되었습니다.

job의 컨테이너에서 서비스에 액세스하기 위한 추가 별칭.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값: 공백 또는 쉼표로 구분된 하나 이상의 별칭이 있는 문자열.

services:alias 예시:

services:
  - name: postgres:11.7
    alias: db,postgres,pg
  - name: mysql:latest
    alias: mysql-1

추가 세부 정보:

여러 별칭은 공백 또는 쉼표로 구분할 수 있습니다.
자세한 내용은 서비스에 액세스하기 및 Kubernetes executor에 대한 서비스 컨테이너 이름으로 별칭 사용을 참조하세요.

`services:docker`#

히스토리

GitLab 16.7에서 도입되었습니다. GitLab Runner 16.7 이상이 필요합니다.
user 입력 옵션이 GitLab 16.8에서 도입되었습니다.

services:docker를 사용하여 GitLab Runner의 Docker executor에 옵션을 전달합니다.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

Docker executor에 대한 옵션의 해시, 다음을 포함할 수 있습니다:

platform: 가져올 이미지의 아키텍처를 선택합니다. 지정하지 않으면 기본값은 호스트 러너와 동일한 플랫폼입니다.
user: 컨테이너를 실행할 때 사용할 사용자 이름 또는 UID를 지정합니다.

services:docker 예시:

arm-sql-job:
  script: echo "Run sql tests in service container"
  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:kubernetes`#

히스토리

GitLab 18.0에서 도입되었습니다. GitLab Runner 17.11 이상이 필요합니다.
user 입력 옵션이 GitLab Runner 17.11에서 도입되었습니다.
user 입력 옵션이 GitLab 18.0에서 uid:gid 형식을 지원하도록 확장되었습니다.

services:kubernetes를 사용하여 GitLab Runner Kubernetes executor에 옵션을 전달합니다.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

Kubernetes executor에 대한 옵션의 해시, 다음을 포함할 수 있습니다:

user: 컨테이너가 실행될 때 사용할 사용자 이름 또는 UID를 지정합니다. UID:GID 형식을 사용하여 GID를 설정할 수도 있습니다.

UID만 사용하는 services:kubernetes 예시:

arm-sql-job:
  script: echo "Run sql tests"
  image: ruby:2.6
  services:
    - name: super/sql:experimental
      kubernetes:
        user: "1001"

UID와 GID 모두 사용하는 services:kubernetes 예시:

arm-sql-job:
  script: echo "Run sql tests"
  image: ruby:2.6
  services:
    - name: super/sql:experimental
      kubernetes:
        user: "1001:1001"

`services:entrypoint`#

컨테이너의 엔트리포인트로 실행할 명령 또는 스크립트.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값: 엔트리포인트 명령을 나타내는 문자열 배열.

services:entrypoint 예시:

services:
  - name: my-postgres:11.7
    entrypoint: ["/usr/local/bin/db-postgres"]

`services:command`#

컨테이너의 명령으로 사용해야 하는 명령 또는 스크립트.

이미지 이름 뒤에 Docker에 전달되는 인수로 변환됩니다. 구문은 각 쉘 토큰이 배열의 별도 문자열인 Dockerfile CMD 지시어와 유사합니다.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값: 명령을 나타내는 문자열 배열.

services:command 예시:

services:
  - name: super/sql:latest
    command: ["/usr/bin/super-sql", "run"]

`services:variables`#

서비스에만 전달되는 추가 환경 변수. 서비스 변수는 서비스 컨테이너에만 전달되며 job 컨테이너에서는 사용할 수 없습니다.

구문은 job 변수와 동일합니다.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값: 환경 변수 이름과 값의 해시.

services:variables 예시:

services:
  - name: postgres:11.7
    alias: db
    variables:
      POSTGRES_DB: "my_custom_db"
      POSTGRES_USER: "postgres"
      POSTGRES_PASSWORD: "example"
      PGDATA: "/var/lib/postgresql/data"

추가 세부 정보:

서비스 변수는 자체를 참조할 수 없으며 변수 확장 또는 보간을 지원하지 않습니다.
job 또는 파이프라인 수준에서 정의된 변수는 서비스에 자동으로 전달됩니다. 자세한 내용은 서비스에 CI/CD 변수 전달을 참조하세요.
서비스 변수는 정의된 특정 서비스에서만 사용할 수 있습니다.

`services:pull_policy`#

히스토리

GitLab 15.1에서 ci_docker_image_pull_policy라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
GitLab 15.2에서 GitLab.com 및 GitLab Self-Managed에서 활성화되었습니다.
GitLab 15.4에서 일반 공개되었습니다. 기능 플래그 ci_docker_image_pull_policy가 제거되었습니다.

러너가 Docker 이미지를 가져오는 데 사용하는 풀 정책. GitLab Runner 15.1 이상이 필요합니다.

키워드 유형: Job 키워드. job의 일부 또는 default 섹션에서만 사용할 수 있습니다.

지원되는 값:

단일 풀 정책 또는 배열의 여러 풀 정책. always, if-not-present, 또는 never일 수 있습니다.

services:pull_policy 예시:

job1:
  script: echo "A single pull policy."
  services:
    - name: postgres:11.6
      pull_policy: if-not-present

job2:
  script: echo "Multiple pull policies."
  services:
    - name: postgres:11.6
      pull_policy: [always, if-not-present]

추가 세부 정보:

러너가 정의된 풀 정책을 지원하지 않으면 job이 다음과 유사한 오류와 함께 실패합니다: ERROR: Job failed (system failure): the configured PullPolicies ([always]) are not allowed by AllowedPullPolicies ([never]).

관련 항목:

`stage`#

stage를 사용하여 job이 실행되는 stage를 정의합니다. 동일한 stage의 job은 병렬로 실행될 수 있습니다 (추가 세부 정보 참조).

stage가 정의되지 않으면 job은 기본적으로 test stage를 사용합니다.

키워드 유형: Job 키워드. job의 일부로만 사용할 수 있습니다.

지원되는 값: 다음일 수 있는 문자열:

기본 stage.
사용자 정의 stage.

stage 예시:

stages:
  - build
  - test
  - deploy

job1:
  stage: build
  script:
    - echo "This job compiles code."

job2:
  stage: test
  script:
    - echo "This job tests the compiled code. It runs when the build stage completes."

job3:
  script:
    - echo "This job also runs in the test stage."

job4:
  stage: deploy
  script:
    - echo "This job deploys the code. It runs when the test stage completes."
  environment: production

추가 세부 정보:

stage 이름은 255자 이하여야 합니다.
Job은 서로 다른 러너에서 실행되는 경우 병렬로 실행될 수 있습니다.
러너가 하나만 있는 경우 러너의 concurrent 설정 이 1보다 크면 Job이 병렬로 실행될 수 있습니다.

`stage: .pre`#

파이프라인에 .pre 또는 .post stage의 Job만 포함된 경우 파이프라인이 실행되지 않습니다. 다른 stage에 적어도 하나의 Job이 있어야 합니다.

키워드 유형: Job의 stage 키워드와 함께만 사용할 수 있습니다.

stage: .pre 예시:

stages:
  - build
  - test

job1:
  stage: build
  script:
    - echo "This job runs in the build stage."

first-job:
  stage: .pre
  script:
    - echo "This job runs in the .pre stage, before all other stages."

job2:
  stage: test
  script:
    - echo "This job runs in the test stage."

추가 세부 정보:

파이프라인에 needs: []인 Job과 .pre stage의 Job이 있는 경우, 파이프라인이 생성되는 즉시 모두 시작됩니다. needs: []인 Job은 stage 설정을 무시하고 즉시 시작됩니다.
파이프라인 실행 정책은 .pre 이전에 실행되는 .pipeline-policy-pre stage를 정의할 수 있습니다.

`stage: .post`#

파이프라인에 .pre 또는 .post stage의 Job만 포함된 경우 파이프라인이 실행되지 않습니다. 다른 stage에 적어도 하나의 Job이 있어야 합니다.

키워드 유형: Job의 stage 키워드와 함께만 사용할 수 있습니다.

stage: .post 예시:

stages:
  - build
  - test

job1:
  stage: build
  script:
    - echo "This job runs in the build stage."

last-job:
  stage: .post
  script:
    - echo "This job runs in the .post stage, after all other stages."

job2:
  stage: test
  script:
    - echo "This job runs in the test stage."

추가 세부 정보:

파이프라인 실행 정책은 .post 이후에 실행되는 .pipeline-policy-post stage를 정의할 수 있습니다.

`tags`#

tags를 사용하여 프로젝트에서 사용 가능한 모든 러너 목록에서 특정 러너를 선택합니다.

키워드 유형: Job 키워드. Job의 일부로만 사용하거나 default 섹션에서 사용할 수 있습니다.

지원되는 값:

대소문자를 구분하는 태그 이름 배열.
CI/CD 변수는 지원됩니다.

tags 예시:

job:
  tags:
    - ruby
    - postgres

이 예시에서 ruby와 postgres 태그가 모두 있는 러너만 Job을 실행할 수 있습니다.

추가 세부 정보:

태그 수는 50개 미만이어야 합니다.

관련 주제:

`timeout`#

timeout을 사용하여 특정 Job의 타임아웃을 설정합니다. Job이 타임아웃보다 오래 실행되면 Job이 실패합니다.

Job 수준 타임아웃은 프로젝트 수준 타임아웃보다 길 수 있지만, 러너의 타임아웃보다 길 수 없습니다.

키워드 유형: Job 키워드. Job의 일부로만 사용하거나 default 섹션에서 사용할 수 있습니다.

지원되는 값: 자연어로 작성된 기간. 예를 들어 다음은 모두 동일합니다:

3600 seconds
60 minutes
one hour

timeout 예시:

build:
  script: build.sh
  timeout: 3 hours 30 minutes

test:
  script: rspec
  timeout: 3h 30m

추가 세부 정보:

timeout 키워드는 default 설정에서 지원되지 않습니다. 대신 개별 job 설정에서 timeout을 정의하세요. 자세한 내용은 이슈 213634를 참조하세요.

`trigger`#

히스토리

GitLab 16.4에서 environment 지원이 도입되었습니다.

trigger를 사용하여 Job이 다음 중 하나인 다운스트림 파이프라인을 시작하는 "트리거 Job"임을 선언합니다:

트리거 Job은 제한된 GitLab CI/CD 설정 키워드 세트만 사용할 수 있습니다. 트리거 Job에서 사용 가능한 키워드:

allow_failure.
extends.
needs, 단 needs:project는 제외.
only 및 except.
parallel.
rules.
stage.
trigger.
variables.
when (on_success, on_failure, always 값만 허용).
resource_group.
environment.

키워드 유형: Job 키워드. Job의 일부로만 사용할 수 있습니다.

지원되는 값:

멀티 프로젝트 파이프라인의 경우 다운스트림 프로젝트 경로. CI/CD 변수는 GitLab 15.3 이상에서 지원되지만, Job 전용 변수는 지원되지 않습니다. 또는 trigger:project를 사용합니다.
자식 파이프라인의 경우 trigger:include를 사용합니다.

trigger 예시:

trigger-multi-project-pipeline:
  trigger: my-group/my-project

추가 세부 정보:

같은 Job에서 trigger와 함께 when:manual을 사용할 수 있지만, API를 사용하여 when:manual 트리거 Job을 시작할 수 없습니다. 자세한 내용은 이슈 284086을 참고하세요.
수동 트리거 Job을 실행하기 전에 CI/CD 변수를 수동으로 지정할 수 없습니다.
최상위 variables 섹션(전역)이나 트리거 Job에 정의된 CI/CD 변수는 트리거 변수로 다운스트림 파이프라인에 전달됩니다.
파이프라인 변수는 기본적으로 다운스트림 파이프라인에 전달되지 않습니다. trigger:forward를 사용하여 이러한 변수를 다운스트림 파이프라인에 전달합니다.
Job 전용 변수는 트리거 Job에서 사용할 수 없습니다.
러너의 config.toml에 정의된 환경 변수는 트리거 Job에서 사용할 수 없으며 다운스트림 파이프라인에 전달되지 않습니다.
트리거 Job에서 needs:pipeline:job을 사용할 수 없습니다.

관련 주제:

멀티 프로젝트 파이프라인 설정 예시.
특정 브랜치, 태그 또는 커밋의 파이프라인을 실행하려면 트리거 토큰을 사용하여 파이프라인 트리거 API로 인증할 수 있습니다. 트리거 토큰은 trigger 키워드와 다릅니다.

`trigger:inputs`#

히스토리

GitLab 17.11에서 도입되었습니다.

다운스트림 파이프라인 설정이 spec:inputs를 사용하는 경우 trigger:inputs를 사용하여 멀티 프로젝트 파이프라인의 inputs를 설정합니다.

trigger:inputs 예시:

trigger:
  - project: 'my-group/my-project'
    inputs:
      website: "My website"

`trigger:include`#

trigger:include를 사용하여 Job이 자식 파이프라인을 시작하는 "트리거 Job"임을 선언합니다.

키워드 유형: Job 키워드. Job의 일부로만 사용할 수 있습니다.

지원되는 값:

자식 파이프라인 설정 파일 경로.

trigger:include 예시:

trigger-child-pipeline:
  trigger:
    include: path/to/child-pipeline.gitlab-ci.yml

추가 세부 정보:

다음을 사용합니다:

trigger:include:artifact: 동적 자식 파이프라인 트리거.
trigger:include:inputs: 다운스트림 파이프라인 설정이 spec:inputs를 사용하는 경우 inputs 설정.
trigger:include:local: 다음의 경우 자식 파이프라인 설정 파일 경로:
- 여러 자식 파이프라인 설정 파일 결합.
- trigger:include:inputs와 결합하여 자식 파이프라인에 inputs 전달. 예:
```
staging-job:
  trigger:
    include:
      - local: path/to/child-pipeline.yml
        inputs:
          environment: staging
```
trigger:include:project: 다른 프로젝트의 설정 파일로 자식 파이프라인 트리거. 파일에 추가 include 항목이 있는 경우 GitLab은 파일을 호스팅하는 프로젝트가 아닌 파이프라인을 실행하는 프로젝트에서 파일을 찾습니다.
trigger:include:template: CI/CD 템플릿으로 자식 파이프라인 트리거.

관련 주제:

자식 파이프라인 설정 예시.

`trigger:include:inputs`#

히스토리

GitLab 17.11에서 도입되었습니다.

다운스트림 파이프라인 설정이 spec:inputs를 사용하는 경우 trigger:include:inputs를 사용하여 자식 파이프라인의 inputs를 설정합니다.

trigger:inputs 예시:

trigger-job:
  trigger:
    include:
      - local: path/to/child-pipeline.yml
        inputs:
          website: "My website"

`trigger:project`#

trigger:project를 사용하여 Job이 멀티 프로젝트 파이프라인을 시작하는 "트리거 Job"임을 선언합니다.

기본적으로 멀티 프로젝트 파이프라인은 기본 브랜치에 대해 트리거됩니다. trigger:branch를 사용하여 다른 브랜치를 지정합니다.

키워드 유형: Job 키워드. Job의 일부로만 사용할 수 있습니다.

지원되는 값:

다운스트림 프로젝트 경로. CI/CD 변수는 GitLab 15.3 이상에서 지원되지만, Job 전용 변수는 지원되지 않습니다.

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`#

히스토리

GitLab 18.2에서 strategy:mirror 옵션이 도입되었습니다.

trigger:strategy를 사용하여 다운스트림 파이프라인이 완료될 때까지 trigger Job이 기다린 후 success로 표시되도록 합니다.

이 동작은 다운스트림 파이프라인이 생성되는 즉시 trigger Job이 success로 표시되는 기본 동작과 다릅니다.

이 설정은 파이프라인 실행을 병렬이 아닌 선형으로 만듭니다.

지원되는 값:

mirror: 다운스트림 파이프라인의 상태를 정확히 미러링합니다.
depend: 권장하지 않음, 대신 mirror를 사용합니다. 트리거 Job 상태는 다운스트림 파이프라인 상태에 따라 failed, success 또는 running을 표시합니다. 추가 세부 정보를 참고하세요.

trigger:strategy 예시:

trigger_job:
  trigger:
    include: path/to/child-pipeline.yml
    strategy: mirror

이 예시에서 이후 stage의 Job은 트리거된 파이프라인이 성공적으로 완료될 때까지 기다린 후 시작됩니다.

추가 세부 정보:

다운스트림 파이프라인의 선택적 수동 Job은 다운스트림 파이프라인이나 업스트림 트리거 Job의 상태에 영향을 주지 않습니다. 다운스트림 파이프라인은 선택적 수동 Job을 실행하지 않고도 성공적으로 완료될 수 있습니다.
기본적으로 이후 stage의 Job은 트리거 Job이 완료될 때까지 시작되지 않습니다.
다운스트림 파이프라인의 차단 수동 Job은 트리거 Job이 성공 또는 실패로 표시되기 전에 실행되어야 합니다.
strategy:depend 사용 시(더 이상 권장하지 않음, 대신 strategy:mirror 사용):
- 수동 Job으로 인해 다운스트림 파이프라인 상태가 waiting for manual action([status_manual])인 경우 트리거 Job은 running([status_running])을 표시합니다.
- 다운스트림 파이프라인에 실패한 Job이 있지만 해당 Job이 allow_failure: true를 사용하는 경우, 다운스트림 파이프라인은 성공으로 간주되고 트리거 Job은 success를 표시합니다.

`trigger:forward`#

히스토리

GitLab 15.1에서 일반 공개되었습니다. 기능 플래그 ci_trigger_forward_variables가 제거되었습니다.

지원되는 값:

yaml_variables: true(기본값) 또는 false. true이면 트리거 Job에 정의된 변수가 다운스트림 파이프라인에 전달됩니다.
pipeline_variables: true 또는 false(기본값). true이면 파이프라인 변수가 다운스트림 파이프라인에 전달됩니다.

trigger:forward 예시:

CI/CD 변수 MYVAR = my value를 사용하여 이 파이프라인을 수동으로 실행합니다:

variables: # default variables for each job
  VAR: value

---

# Default behavior:
---

# - VAR is passed to the child
---

# - MYVAR is not passed to the child
child1:
  trigger:
    include: .child-pipeline.yml

---

# Forward pipeline variables:
---

# - VAR is passed to the child
---

# - MYVAR is passed to the child
child2:
  trigger:
    include: .child-pipeline.yml
    forward:
      pipeline_variables: true

---

# Do not forward YAML variables:
---

# - VAR is not passed to the child
---

# - MYVAR is not passed to the child
child3:
  trigger:
    include: .child-pipeline.yml
    forward:
      yaml_variables: false

추가 세부 정보:

trigger:forward로 다운스트림 파이프라인에 전달된 CI/CD 변수는 파이프라인 변수이며 높은 우선순위를 가집니다. 다운스트림 파이프라인에 같은 이름의 변수가 정의되어 있으면 해당 변수는 일반적으로 전달된 변수에 의해 덮어씌워집니다.

`when`#

when을 사용하여 Job이 실행되는 조건을 설정합니다. Job에 정의되지 않은 경우 기본값은 when: on_success입니다.

키워드 유형: Job 키워드. Job의 일부로 사용할 수 있습니다. when: always와 when: never는 workflow:rules에서도 사용할 수 있습니다.

지원되는 값:

on_success(기본값): 이전 stage의 Job이 실패하지 않은 경우에만 Job을 실행합니다.
on_failure: 이전 stage에서 적어도 하나의 Job이 실패한 경우에만 Job을 실행합니다.
never: 이전 stage의 Job 상태에 관계없이 Job을 실행하지 않습니다. rules 섹션이나 workflow: rules에서만 사용할 수 있습니다.
always: 이전 stage의 Job 상태에 관계없이 Job을 실행합니다.
manual: Job을 수동 Job으로 파이프라인에 추가합니다.
delayed: Job을 지연 Job으로 파이프라인에 추가합니다.

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을 실행합니다.

추가 세부 정보:

on_success와 on_failure의 Job 상태 평가 시:
- 이전 stage에서 allow_failure: true인 Job은 실패하더라도 성공으로 간주됩니다.
- 이전 stage에서 건너뛴 Job(예: 시작되지 않은 수동 Job)은 성공으로 간주됩니다.
when: manual인 경우 allow_failure의 기본값은 true입니다. rules:when: manual에서는 기본값이 false로 변경됩니다.

관련 주제:

when은 더 동적인 Job 제어를 위해 rules와 함께 사용할 수 있습니다.
when은 파이프라인 시작 가능 시점을 제어하기 위해 workflow와 함께 사용할 수 있습니다.

`manual_confirmation`#

히스토리

GitLab 17.1에서 도입되었습니다.
GitLab 18.3에서 환경 중지 Job에 대한 지원이 도입되었습니다.

수동 확인은 environment:action: stop을 사용하는 환경 중지 Job을 포함한 모든 수동 Job에서 작동합니다.

키워드 유형: Job 키워드. Job의 일부로만 사용할 수 있습니다.

지원되는 값:

확인 메시지 문자열.

manual_confirmation 예시:

delete_job:
  stage: post-deployment
  script:
    - make delete
  when: manual
  manual_confirmation: 'Are you sure you want to delete this environment?'

stop_production:
  stage: cleanup
  script:
    - echo "Stopping production environment"
  environment:
    name: production
    action: stop
  when: manual
  manual_confirmation: "Are you sure you want to stop the production environment?"

`start_in`#

지정된 기간 후 Job 실행을 지연하려면 start_in을 사용합니다. Job에 when: delayed를 설정해야 합니다.

키워드 유형: Job 키워드. Job의 일부로만 사용할 수 있습니다.

가능한 입력값: 초, 분 또는 시간 단위의 기간. 1주일 이하여야 합니다. 유효한 값 예시:

'5' (5초)
'10 seconds'
'30 minutes'
'1 hour'
'1 day'

start_in 예시:

deploy_production:
  stage: deploy
  script:
    - echo "Deploying to production"
  when: delayed
  start_in: 30 minutes

이 예시에서 deploy_production Job은 이전 stage가 완료된 후 30분이 지나면 시작됩니다.

추가 세부 정보:

타이머는 이전 Job이 완료될 때가 아니라 Job의 stage가 시작될 때부터 시작됩니다.
지연된 Job을 즉시 수동으로 시작하려면 파이프라인 뷰에서 Play([play])를 선택합니다.
최소 지연 기간은 1초이고 최대 지연은 1주일입니다.
start_in은 when이 delayed로 설정된 경우에만 작동합니다. when에 다른 값을 사용하면 설정이 유효하지 않습니다. Job에 rules를 사용하는 경우 start_in과 when은 Job 수준이 아닌 rules에서 정의해야 합니다. 그렇지 않으면 유효성 검사 오류가 발생합니다: config key may not be used with 'rules': start_in.
start_in은 workflow:rules에서 지원되지 않지만 구문 위반이 발생하지는 않습니다.

관련 주제:

지연 후 Job 실행

`variables`#

variables를 사용하여 CI/CD 변수를 정의합니다.

변수는 CI/CD Job에 정의하거나 최상위(전역) 키워드로 정의하여 모든 Job의 기본 CI/CD 변수로 사용할 수 있습니다.

추가 세부 정보:

YAML로 정의된 모든 변수는 연결된 Docker 서비스 컨테이너에도 설정됩니다.
YAML로 정의된 변수는 민감하지 않은 프로젝트 설정을 위한 것입니다. 민감한 정보는 보호된 변수 또는 CI/CD 시크릿에 저장합니다.
수동 파이프라인 변수와 예약된 파이프라인 변수는 기본적으로 다운스트림 파이프라인에 전달되지 않습니다. trigger:forward를 사용하여 이러한 변수를 다운스트림 파이프라인에 전달합니다.

관련 주제:

사전 정의된 변수는 러너가 자동으로 생성하여 Job에서 사용할 수 있게 하는 변수입니다.
변수를 사용하여 러너 동작을 설정할 수 있습니다.

Job `variables`#

Job 변수는 include와 같은 전역 키워드의 값으로 사용할 수 없습니다.

지원되는 값: 변수 이름 및 값 쌍:

이름에는 숫자, 문자, 밑줄(_)만 사용할 수 있습니다. 일부 쉘에서는 첫 번째 문자가 문자여야 합니다.
값은 문자열이어야 합니다.

CI/CD 변수는 지원됩니다.

Job variables 예시:

review_job:
  variables:
    DEPLOY_SITE: "https://dev.example.com/"
    REVIEW_PATH: "/review"
  script:
    - deploy-review-script --url $DEPLOY_SITE --path $REVIEW_PATH

이 예시에서:

review_job에는 DEPLOY_SITE와 REVIEW_PATH Job 변수가 정의되어 있습니다. 두 Job 변수 모두 script 섹션에서 사용할 수 있습니다.

Default `variables`#

최상위 variables 섹션에 정의된 변수는 모든 Job의 기본 변수로 작동합니다.

Job 변수와 마찬가지로 기본 변수는 include와 같은 다른 전역 키워드의 값으로 사용할 수 없습니다.

지원되는 값: 변수 이름 및 값 쌍:

이름에는 숫자, 문자, 밑줄(_)만 사용할 수 있습니다. 일부 쉘에서는 첫 번째 문자가 문자여야 합니다.
값은 문자열이어야 합니다.

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:
    DEPLOY_SITE: "https://dev.example.com/"
    REVIEW_PATH: "/review"
  script:
    - deploy-review-script --url $DEPLOY_SITE --path $REVIEW_PATH
  environment: production

이 예시에서:

deploy_job에는 정의된 변수가 없습니다. 기본 DEPLOY_SITE 변수가 Job에 복사되어 script 섹션에서 사용할 수 있습니다.
deploy_review_job에는 이미 DEPLOY_SITE 변수가 정의되어 있으므로 기본 DEPLOY_SITE는 Job에 복사되지 않습니다. Job에는 REVIEW_PATH Job 변수도 정의되어 있습니다. 두 Job 변수 모두 script 섹션에서 사용할 수 있습니다.

`variables:description`#

키워드 유형: 기본 variables에서만 사용할 수 있으며, Job variables에서는 사용할 수 없습니다.

지원되는 값:

문자열. Markdown을 사용할 수 있습니다.

variables:description 예시:

variables:
  DEPLOY_NOTE:
    description: "The deployment note. Explain the reason for this deployment."

추가 세부 정보:

value 없이 사용하면 수동으로 트리거되지 않은 파이프라인에 변수가 존재하며 기본값은 빈 문자열('')입니다.

`variables:value`#

키워드 유형: 기본 variables에서만 사용할 수 있으며, Job variables에서는 사용할 수 없습니다.

지원되는 값:

문자열.

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에서만 사용할 수 있으며, Job variables에서는 사용할 수 없습니다.

지원되는 값:

문자열 배열.

variables:options 예시:

variables:
  DEPLOY_ENVIRONMENT:
    value: "staging"
    options:
      - "production"
      - "staging"
      - "canary"
    description: "The deployment target. Set to 'staging' by default."

`variables:expand`#

히스토리

GitLab 15.6에서 ci_raw_variables_in_yaml_config라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화됩니다.
GitLab 15.6에서 GitLab.com에서 활성화되었습니다.
GitLab 15.7에서 GitLab Self-Managed에서 활성화되었습니다.
GitLab 15.8에서 일반 공개되었습니다. 기능 플래그 ci_raw_variables_in_yaml_config가 제거되었습니다.

expand 키워드를 사용하여 변수를 확장 가능 여부를 설정합니다.

키워드 유형: 기본 및 Job variables 모두에서 사용할 수 있습니다.

지원되는 값:

true(기본값): 변수가 확장됩니다.
false: 변수가 확장되지 않습니다.

variables:expand 예시:

variables:
  VAR1: value1
  VAR2: value2 $VAR1
  VAR3:
    value: value3 $VAR1
    expand: false

VAR2의 결과는 value2 value1입니다.
VAR3의 결과는 value3 $VAR1입니다.

추가 세부 정보:

expand 키워드는 기본 및 Job variables 키워드에서만 사용할 수 있습니다. rules:variables 또는 workflow:rules:variables에서는 사용할 수 없습니다.

GitLab 템플릿 컬렉션에서 가져온 파일

키워드#

전역 키워드#

default#

include#

include:component#

include:local#

include:project#

include:remote#

include:template#

include:inputs#

include:rules#

include:integrity#

include:cache#

stages#

workflow#

workflow:auto_cancel:on_new_commit#

workflow:auto_cancel:on_job_failure#

workflow:name#

workflow:rules#

workflow:rules:variables#

workflow:rules:auto_cancel#

헤더 키워드#

spec#

spec:inputs#

spec:inputs:default#

spec:inputs:description#

spec:inputs:options#

spec:inputs:regex#

spec:inputs:rules#

spec:inputs:type#

spec:include#

spec:component#

spec:description#

Job 키워드#

after_script#

allow_failure#

allow_failure:exit_codes#

artifacts#

artifacts:paths#

artifacts:exclude#

artifacts:expire_in#

artifacts:expose_as#

artifacts:name#

artifacts:public#

artifacts:access#

artifacts:reports#

artifacts:untracked#

artifacts:when#

before_script#

cache#

cache:paths#

cache:key#

cache:key:files#

cache:key:files_commits#

cache:key:prefix#

cache:untracked#

cache:unprotect#

cache:when#

cache:policy#

cache:fallback_keys#

coverage#

dast_configuration#

dependencies#

environment#

environment:name#

environment:url#

environment:on_stop#

environment:action#

environment:auto_stop_in#

environment:kubernetes#

environment:deployment_tier#

동적 환경#

extends#

hooks#

hooks:pre_get_sources_script#

identity#

id_tokens#

image#

image:name#

`default`#

`include`#

`include:component`#

`include:local`#

`include:project`#

`include:remote`#

`include:template`#

`include:inputs`#

`include:rules`#

`include:integrity`#

`include:cache`#

`stages`#

`workflow`#

`workflow:auto_cancel:on_new_commit`#

`workflow:auto_cancel:on_job_failure`#

`workflow:name`#

`workflow:rules`#

`workflow:rules:variables`#

`workflow:rules:auto_cancel`#

`spec`#

`spec:inputs`#

`spec:inputs:default`#

`spec:inputs:description`#

`spec:inputs:options`#

`spec:inputs:regex`#

`spec:inputs:rules`#

`spec:inputs:type`#

`spec:include`#

`spec:component`#

`spec:description`#

`after_script`#

`allow_failure`#

`allow_failure:exit_codes`#

`artifacts`#

`artifacts:paths`#

`artifacts:exclude`#

`artifacts:expire_in`#

`artifacts:expose_as`#

`artifacts:name`#

`artifacts:public`#

`artifacts:access`#

`artifacts:reports`#

`artifacts:untracked`#

`artifacts:when`#

`before_script`#

`cache`#

`cache:paths`#

`cache:key`#

`cache:key:files`#

`cache:key:files_commits`#

`cache:key:prefix`#

`cache:untracked`#

`cache:unprotect`#

`cache:when`#

`cache:policy`#

`cache:fallback_keys`#

`coverage`#

`dast_configuration`#

`dependencies`#

`environment`#

`environment:name`#

`environment:url`#

`environment:on_stop`#

`environment:action`#

`environment:auto_stop_in`#

`environment:kubernetes`#

`environment:deployment_tier`#

`extends`#

`hooks`#

`hooks:pre_get_sources_script`#

`identity`#

`id_tokens`#

`image`#

`image:name`#

`image:entrypoint`#

`image:docker`#

`image:kubernetes`#

`image:pull_policy`#

`inputs`#

`inputs:default`#