키워드
전역 키워드
헤더 키워드
- spec
  - spec:inputs
작업 키워드
사용 중단된 키워드
- 전역으로 정의된 image, services, cache, before_script, after_script
- only / except

CI/CD YAML 구문 참조

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

이 문서는 GitLab .gitlab-ci.yml 파일의 구성 옵션을 나열합니다.
이 파일은 파이프라인을 구성하는 CI/CD 작업을 정의하는 곳입니다.

기본 CI/CD 개념에 익숙하다면,
간단한 또는 복잡한 파이프라인을 보여주는 튜토리얼을 따라
자신만의 .gitlab-ci.yml 파일을 만들어 보세요.
예제 모음은 GitLab CI/CD 예제를 참조하세요.
기업에서 사용되는 대규모 .gitlab-ci.yml 파일을 보려면,
.gitlab-ci.yml 파일 for gitlab을 참조하세요.

.gitlab-ci.yml 파일을 편집하는 동안,
CI Lint 도구로 이를 검증할 수 있습니다.

이 페이지의 내용을 편집하고 있다면,
키워드 문서화 지침을 따르세요.

키워드

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

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

키워드	설명
`default`	작업 키워드에 대한 사용자 정의 기본값.
`include`	다른 YAML 파일에서 구성 가져오기.
`stages`	파이프라인 단계의 이름과 순서.
`variables`	파이프라인의 모든 작업에 대한 CI/CD 변수 정의.
`workflow`	파이프라인 실행 유형 제어.

헤더 키워드

키워드 설명

spec 외부 구성 파일에 대한 사양 정의.

키워드	설명
`spec`	외부 구성 파일에 대한 사양 정의.

작업과 작업 키워드로 구성된:

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

전역 키워드

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

`default`

id_tokens에 대한 지원이 GitLab 16.4에서 도입됨.

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

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

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

after_script
artifacts
before_script
cache
hooks
id_tokens
image
interruptible
retry
services
tags
timeout, 그러나 문제 213634로 인해 이 키워드는 효과가 없습니다.

default의 예:

default:
  image: ruby:3.0
  retry: 2

rspec:
  script: bundle exec rspec

rspec 2.7:
  image: ruby:2.7
  script: bundle exec rspec

이 예에서는:

image: ruby:3.0 및 retry: 2는 파이프라인의 모든 작업에 대한 기본 키워드입니다.
rspec 작업은 image 또는 retry가 정의되어 있지 않으므로 image: ruby:3.0 및 retry: 2의 기본값을 사용합니다.
rspec 2.7 작업은 retry가 정의되어 있지 않지만, image가 명시적으로 정의되어 있습니다. 기본 retry: 2를 사용하지만 기본 image를 무시하고 작업에서 정의된 image: ruby:2.7을 사용합니다.

추가 세부 정보:

inherit:default를 사용하여 작업에서 기본 키워드의 상속을 제어합니다.
전역 기본값은 하위 파이프라인으로 전달되지 않으며, 이는 상위 파이프라인과 독립적으로 실행됩니다.

`include`

include를 사용하여 CI/CD 구성에 외부 YAML 파일을 포함합니다.

하나의 긴 .gitlab-ci.yml 파일을 여러 개의 파일로 분할하여 가독성을 높이거나, 여러 위치에서 동일한 구성을 중복하지 않도록 할 수 있습니다.

템플릿 파일을 중앙 저장소에 저장하고 프로젝트에 포함할 수도 있습니다.

include 파일은 다음과 같습니다:

.gitlab-ci.yml 파일의 내용과 병합됩니다.
항상 먼저 평가된 다음 .gitlab-ci.yml 파일의 내용과 병합되며, include 키워드의 위치와는 무관합니다.

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

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

가능한 입력: include 하위 키는 다음과 같습니다:

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

그리고 선택적으로:

include:inputs
include:rules

추가 세부 정보:

include 키워드와 함께 사용할 수 있는 특정 CI/CD 변수만 사용할 수 있습니다.
병합을 사용하여 포함된 CI/CD 구성을 지역적으로 사용자 정의 및 재정의할 수 있습니다.
동일한 작업 이름 또는 전역 키워드가 .gitlab-ci.yml 파일에 있는 경우, 포함된 구성을 재정의할 수 있습니다. 두 구성은 함께 병합되며, .gitlab-ci.yml 파일의 구성이 포함된 구성보다 우선합니다.
작업을 다시 실행하면:
- include 파일은 다시 가져오지 않습니다. 파이프라인의 모든 작업은 파이프라인이 생성될 때 가져온 구성으로 사용합니다. 원본 include 파일의 변경 사항은 작업 재실행에 영향을 미치지 않습니다.
- 파이프라인을 다시 실행하면 include 파일이 다시 가져옵니다. 마지막 파이프라인 실행 후 변경된 경우, 새 파이프라인은 변경된 구성을 사용합니다.
기본적으로 파이프라인당 최대 150개의 포함을 가질 수 있으며, 중첩 포함도 포함됩니다. 또한:
- GitLab 16.0 이상에서 자가 관리 사용자는 최대 포함 값을 변경할 수 있습니다.
- GitLab 15.10 이상에서 최대 150개의 포함을 가질 수 있습니다. 중첩 포함에서 동일한 파일을 여러 번 포함할 수 있지만 중복 포함은 제한에 포함됩니다.
- GitLab 14.9에서 GitLab 15.9까지 최대 100개의 포함을 가질 수 있습니다. 중첩 포함에서 동일한 파일을 여러 번 포함할 수 있지만 중복은 무시됩니다.

`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: 선택적. 파일을 가져올 참조. 지정하지 않을 경우 프로젝트의 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 파일을 포함할 때, 파이프라인을 실행하는 사용자는 두 프로젝트 모두의 구성원이며 파이프라인을 실행할 수 있는 적절한 권한을 가져야 합니다. 포함된 파일에 접근할 수 없는 경우 찾을 수 없거나 접근이 거부됨 오류가 표시될 수 있습니다.
다른 프로젝트의 CI/CD 구성 파일을 포함할 때는 주의하세요. CI/CD 구성 파일이 변경될 때는 파이프라인이나 알림이 트리거되지 않습니다. 보안 관점에서 이는 제3자 종속성을 끌어오는 것과 유사합니다. ref를 고려할 때:
- 가장 안정적인 옵션인 특정 SHA 해시를 사용하는 것이 좋습니다. 원하는 커밋이 참조되도록 전체 40자 SHA 해시를 사용하세요. ref에 대해 짧은 SHA 해시를 사용하면 모호할 수 있습니다.
- 다른 프로젝트의 ref에 대해 보호된 브랜치 및 보호된 태그 규칙을 적용합니다. 보호된 태그와 브랜치는 변경되기 전에 변경 관리 절차를 통과할 가능성이 더 높습니다.

`include:remote`

include:remote를 사용하여 다른 위치에서 파일을 포함하려면 전체 URL을 사용하세요.

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

가능한 입력:

HTTP/HTTPS GET 요청으로 접근할 수 있는 공개 URL:

원격 URL에 대한 인증은 지원되지 않습니다.
YAML 파일은 .yml 또는 .yaml 확장자를 가져야 합니다.
특정 CI/CD 변수를 사용할 수 있습니다.

include:remote의 예:

include:
  - remote: 'https://gitlab.com/example-project/-/raw/main/.gitlab-ci.yml'

추가 세부사항:

모든 중첩 포함은 공개 사용자로서 상황 없이 실행되므로, 공개 프로젝트나 템플릿만 포함할 수 있습니다. 중첩 포함의 include 섹션에서는 변수가 사용할 수 없습니다.
다른 프로젝트의 CI/CD 구성 파일을 포함할 때 주의하세요. 다른 프로젝트의 파일이 변경될 때 파이프라인이나 알림이 트리거되지 않습니다. 보안 관점에서 이는 제 3자 종속성을 끌어오는 것과 유사합니다. 소유하는 다른 GitLab 프로젝트에 링크하는 경우, 변경 관리 규칙을 시행하기 위해 보호된 브랜치 및 보호된 태그의 사용을 고려하세요.

`include:template`

include:template을 사용하여 .gitlab-ci.yml 템플릿을 포함하세요.

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

가능한 입력:

CI/CD 템플릿:

모든 템플릿은 lib/gitlab/ci/templates에서 확인할 수 있습니다. 모든 템플릿이 include:template과 함께 사용되도록 설계된 것은 아니므로 사용하기 전에 템플릿 주석을 확인하세요.
특정 CI/CD 변수를 사용할 수 있습니다.

include:template의 예:

# GitLab 템플릿 컬렉션에서 소스된 파일
include:
  - template: Auto-DevOps.gitlab-ci.yml

여러 include:template 파일:

include:
  - template: Android-Fastlane.gitlab-ci.yml
  - template: Auto-DevOps.gitlab-ci.yml

추가 세부사항:

모든 중첩 포함은 공개 사용자로서 상황 없이 실행되므로, 공개 프로젝트나 템플릿만 포함할 수 있습니다. 중첩 포함의 include 섹션에서는 변수가 사용할 수 없습니다.

`include:inputs`

GitLab 15.11에서 베타 기능으로 도입됨.

GitLab 17.0에서 일반 사용 가능.

include:inputs를 사용하여 포함된 구성이 spec:inputs를 사용할 때 입력 매개변수의 값을 설정하고, 파이프라인에 추가됩니다.

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

가능한 입력: 문자열, 숫자 값 또는 불리언.

include:inputs의 예:

include:
  - local: 'custom_configuration.yml'
    inputs:
      website: "My website"

이 예에서:

custom_configuration.yml에 포함된 구성은 파이프라인에 추가되며, 포함된 구성에 대해 website 입력 값이 “My website”로 설정됩니다.

추가 세부사항:

포함된 구성 파일이 spec:inputs:type를 사용하는 경우, 입력 값은 정의된 유형과 일치해야 합니다.
포함된 구성 파일이 spec:inputs:options를 사용하는 경우, 입력 값은 나열된 옵션 중 하나와 일치해야 합니다.

관련 주제:

include 사용 시 입력 값 설정.

`include:rules`

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

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

가능한 입력: 이 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.

`stages`

GitLab 16.9에서 소개된 문자열의 중첩 배열 지원.

stages를 사용하여 작업 그룹을 포함하는 단계를 정의합니다. 특정 단계에서 실행되도록 작업을 구성하려면 stage를 작업에 사용하세요.

.gitlab-ci.yml 파일에 stages가 정의되지 않은 경우, 기본 파이프라인 단계는 다음과 같습니다:

.pre
build
test
deploy
.post

stages의 항목 순서는 작업 실행 순서를 정의합니다:

같은 단계의 작업은 병렬로 실행됩니다.
다음 단계의 작업은 이전 단계의 작업이 성공적으로 완료된 후에 실행됩니다.

파이프라인에 .pre 또는 .post 단계의 작업만 포함된 경우, 실행되지 않습니다.

다른 단계에 적어도 하나의 작업이 있어야 합니다. .pre 및 .post 단계는 필수 파이프라인 구성에서 프로젝트 파이프라인 작업 전에 또는 후에 실행해야 하는 준수 작업을 정의하는 데 사용할 수 있습니다.

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

stages의 예:

stages:
  - build
  - test
  - deploy

이 예제에서:

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

어떤 작업이라도 실패할 경우, 파이프라인은 failed로 표시되며 이후 단계의 작업은 시작되지 않습니다. 현재 단계의 작업은 중지되지 않고 계속 실행됩니다.

추가 세부정보:

작업이 stage를 지정하지 않으면, 해당 작업은 test 단계로 배정됩니다.
단계가 정의되어 있지만 사용하지 않는 작업이 없으면, 해당 단계는 파이프라인에 표시되지 않으며, 이는 준수 파이프라인 구성에 도움이 될 수 있습니다:
- 준수 구성에서 단계는 정의될 수 있지만 사용되지 않으면 숨겨집니다.
- 정의된 단계는 개발자가 작업 정의에서 사용할 때 가시화됩니다.

관련 주제:

작업이 더 일찍 시작되고 단계 순서를 무시하도록 하려면 needs 키워드를 사용하세요.

`workflow`

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

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

관련 주제:

`workflow:auto_cancel:on_new_commit`

도입됨 GitLab 16.8에서 ci_workflow_auto_cancel_on_new_commit라는 플래그와 함께. 기본적으로 비활성화되어 있습니다.

GitLab.com 및 자체 관리에서 활성화됨 GitLab 16.9에서.

일반적으로 사용 가능 GitLab 16.10에서. 기능 플래그 ci_workflow_auto_cancel_on_new_commit가 제거됨.

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

가능한 입력:

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

workflow:auto_cancel:on_new_commit의 예:

workflow:
  auto_cancel:
    on_new_commit: interruptible

job1:
  interruptible: true
  script: sleep 60

job2:
  interruptible: false  # 정의되지 않았을 때의 기본값.
  script: sleep 60

이 예제에서:

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

`workflow:auto_cancel:on_job_failure`

도입됨 GitLab 16.10에서 auto_cancel_pipeline_on_job_failure라는 플래그와 함께. 기본적으로 비활성화되어 있습니다.

일반적으로 사용 가능 GitLab 16.11에서. 기능 플래그 auto_cancel_pipeline_on_job_failure가 제거됨.

workflow:auto_cancel:on_job_failure를 사용하여 하나의 작업이 실패하면 어떤 작업을 즉시 취소해야 하는지 구성합니다.

가능한 입력:

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

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.com 및 셀프 관리에서 활성화됨 - GitLab 15.7에서.

일반적으로 사용 가능 - GitLab 15.8에서. 기능 플래그 pipeline_name 제거됨.

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

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

가능한 입력:

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

workflow:name의 예시:

프리미엄 변수를 사용한 간단한 파이프라인 이름:

workflow:
  name: '브랜치에 대한 파이프라인: $CI_COMMIT_BRANCH'

파이프라인 조건에 따라 서로 다른 파이프라인 이름을 사용하는 구성:

variables:
  PROJECT1_PIPELINE_NAME: '기본 파이프라인 이름'  # 기본값은 필요 없음.

workflow:
  name: '$PROJECT1_PIPELINE_NAME'
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      variables:
        PROJECT1_PIPELINE_NAME: 'MR 파이프라인: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME'
    - if: '$CI_MERGE_REQUEST_LABELS =~ /pipeline:run-in-ruby3/'
      variables:
        PROJECT1_PIPELINE_NAME: '루비 3 파이프라인'
    - when: always  # 다른 파이프라인은 실행될 수 있지만 기본 이름을 사용

추가 세부정보:

이름이 빈 문자열인 경우 파이프라인에 이름이 할당되지 않습니다. CI/CD 변수만으로 구성된 이름은 모든 변수가 비어 있으면 빈 문자열로 평가될 수 있습니다.
workflow:rules:variables는 모든 작업에서 사용 가능한 전역 변수가 되며, 기본적으로 하위 파이프라인으로 변수를 전달하는 trigger 작업에도 적용됩니다. 하위 파이프라인이 동일한 변수를 사용하는 경우 변수는 덮어쓰기됩니다. 다음을 확인하세요:
- 각 프로젝트의 파이프라인 구성에서 고유한 변수 이름을 사용하세요, 예: PROJECT1_PIPELINE_NAME.
- 트리거 작업에서 inherit:variables를 사용하고 하위 파이프라인에 전달할 특정 변수를 나열하세요.

`workflow:rules`

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

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

가능한 입력: 작업 수준의 rules와 일부 동일한 키워드를 사용할 수 있습니다:

rules: if.
rules: changes.
rules: exists.
when, workflow와 함께 사용할 때는 always 또는 never만 가능합니다.
variables.

workflow:rules의 예시:

workflow:
  rules:
    - if: $CI_COMMIT_TITLE =~ /-draft$/
      when: never
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

이 예시에서 파이프라인은 커밋 제목(커밋 메시지의 첫 번째 줄)이 -draft로 끝나지 않고 파이프라인이 다음 중 하나일 때 실행됩니다:

머지 요청
기본 브랜치.

추가 세부정보:

규칙이 기본 브랜치가 아닌 다른 브랜치 파이프라인과 머지 요청 파이프라인 모두와 일치하면, 중복 파이프라인이 발생할 수 있습니다.

관련 주제:

`workflow:rules:variables`

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

조건이 일치하면 변수가 생성되며 파이프라인의 모든 작업에서 사용할 수 있습니다.

변수가 전역 수준에서 이미 정의되어 있는 경우, workflow 변수는 우선하며 글로벌 변수를 재정의합니다.

키워드 유형: 글로벌 키워드.

가능한 입력: 변수 이름 및 값 쌍:

이름은 숫자, 문자 및 언더스코어(_)만 사용할 수 있습니다.
값은 문자열이어야 합니다.

workflow:rules:variables 예제:

variables:
  DEPLOY_VARIABLE: "default-deploy"

workflow:
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      variables:
        DEPLOY_VARIABLE: "deploy-production"  # 글로벌로 정의된 DEPLOY_VARIABLE 재정의
    - if: $CI_COMMIT_REF_NAME =~ /feature/
      variables:
        IS_A_FEATURE: "true"                  # 새로운 변수 정의.
    - when: always                            # 다른 경우 파이프라인 실행

job1:
  variables:
    DEPLOY_VARIABLE: "job1-default-deploy"
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      variables:                                   # 정의된 DEPLOY_VARIABLE 재정의
        DEPLOY_VARIABLE: "job1-deploy-production"  # 작업 수준에서.
    - when: on_success                             # 다른 경우 작업 실행
  script:
    - echo "Run script with $DEPLOY_VARIABLE as an argument"
    - echo "Run another script if $IS_A_FEATURE exists"

job2:
  script:
    - echo "Run script with $DEPLOY_VARIABLE as an argument"
    - echo "Run another script if $IS_A_FEATURE exists"

브랜치가 기본 브랜치인 경우:

job1의 DEPLOY_VARIABLE은 job1-deploy-production입니다.
job2의 DEPLOY_VARIABLE은 deploy-production입니다.

브랜치가 feature인 경우:

job1의 DEPLOY_VARIABLE은 job1-default-deploy이고, IS_A_FEATURE는 true입니다.
job2의 DEPLOY_VARIABLE은 default-deploy이고, IS_A_FEATURE는 true입니다.

다른 브랜치인 경우:

job1의 DEPLOY_VARIABLE은 job1-default-deploy입니다.
job2의 DEPLOY_VARIABLE은 default-deploy입니다.

추가 세부사항:

workflow:rules:variables는 모든 작업에서 사용할 수 있는 전역 변수가 되며, trigger 작업을 포함하여 기본적으로 변수를 하위 파이프라인으로 전달합니다. 만약 하위 파이프라인이 동일한 변수를 사용할 경우, 변수는 재정의됩니다. 다음을 반드시 확인하세요:
- 각 프로젝트의 파이프라인 구성에서 독특한 변수 이름 사용, 예: PROJECT1_VARIABLE_NAME.
- trigger 작업에서 inherit:variables를 사용하고 하위 파이프라인으로 전달할 정확한 변수를 나열하세요.

`workflow:rules:auto_cancel`

GitLab 16.8에서 도입됨 ci_workflow_auto_cancel_on_new_commit라는 플래그와 함께. 기본적으로 비활성화되어 있습니다.

GitLab 16.9에서 GitLab.com 및 셀프 관리에서 활성화됨.

GitLab 16.10에서 일반적으로 사용 가능. 기능 플래그 ci_workflow_auto_cancel_on_new_commit 제거됨.

GitLab 16.10에서 도입된 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                  # 다른 경우 파이프라인 실행

test-job1:
  script: sleep 10
  interruptible: false

test-job2:
  script: sleep 10
  interruptible: true

이 예제에서, workflow:auto_cancel:on_new_commit 은 모든 작업에 대해 기본적으로 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에서 베타 기능으로 도입됨.

YAML 파일의 헤더에 spec 섹션을 추가하여 include 키워드를 사용하여 구성 파이프라인의 동작을 설정할 수 있습니다.

`spec:inputs`

spec:inputs를 사용하여 include로 파이프라인에 추가하려는 CI/CD 구성의 입력 매개변수를 정의할 수 있습니다. include:inputs를 사용하여 파이프라인이 실행될 때 사용할 값을 정의합니다.

입력을 사용하여 CI/CD 구성에 포함되었을 때 구성의 동작을 사용자 지정하세요.

$[[ inputs.input-id ]]의 보간 형식을 사용하여 헤더 섹션 외부의 값을 참조합니다.

입력은 파이프라인 생성 중 구성 파일이 가져올 때 평가되고 보간되지만, 구성이 .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를 사용하여 기본값을 설정하지 않는 한 필수입니다.
입력은 문자열을 예상하지만 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: ''
---

# 파이프라인 구성은 그 뒤를 따릅니다...

이 예에서:

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: '플래그 입력 세부 사항의 샘플 설명입니다.'
---

# 파이프라인 구성은 이어집니다...

`spec:inputs:options`

도입됨 GitLab 16.6에서.

입력은 options를 사용하여 입력에 대한 허용 값 목록을 지정할 수 있습니다. 제한은 입력당 50개 옵션입니다.

키워드 유형: 헤더 키워드. spec은 구성 파일 상단에, 헤더 섹션에서 선언되어야 합니다.

가능한 입력: 입력 옵션의 배열입니다.

spec:inputs:options의 예:

spec:
  inputs:
    environment:
      options:
        - development
        - staging
        - production
---

# 파이프라인 구성은 이어집니다...

이 예에서:

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

추가 세부 사항:

입력이 다음과 같은 경우 유효성 검사 오류로 인해 파이프라인이 실패합니다:
- 입력이 options와 default를 모두 사용하는 경우, 기본값이 나열된 옵션 중 하나가 아닐 경우.
- 입력 옵션 중 어떤 것도 type와 일치하지 않을 경우, 이는 string 또는 number일 수 있지만, options를 사용할 때는 boolean이 아닙니다.

`spec:inputs:regex`

도입됨 GitLab 16.5에서.

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

키워드 유형: 헤더 키워드. spec은 구성 파일 상단에, 헤더 섹션에서 선언되어야 합니다.

가능한 입력: 정규 표현식이어야 합니다.

spec:inputs:regex의 예:

spec:
  inputs:
    version:
      regex: ^v\d\.\d+(\.\d+)$
---

# 파이프라인 구성은 이어집니다...

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

추가 세부 사항:

inputs:regex는 type가 string일 때만 사용할 수 있으며, number나 boolean은 사용할 수 없습니다.
정규 표현식을 / 문자로 감싸지 마십시오. 예를 들어, regex.*을 사용하고 /regex.*/는 사용하지 마십시오.
inputs:regex는 정규 표현식을 해석하기 위해 RE2를 사용합니다.

`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
---

# 파이프라인 구성은 이어집니다...

작업 키워드

다음 주제에서는 CI/CD 파이프라인을 구성하기 위해 키워드를 사용하는 방법을 설명합니다.

`after_script`

GitLab 17.0에서 소개된 취소된 작업에 대한 after_script 명령 실행.

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

작업이 before_script 또는 script 섹션이 아직 실행 중인 상태에서 취소된 경우.
작업이 script_failure 실패 유형으로 실패하지만 기타 실패 유형은 아닙니다.

Keyword type: 작업 키워드입니다. 작업의 일부로서만 사용하거나 default 섹션에서 사용할 수 있습니다.

Possible inputs: 다음을 포함하는 배열:

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

after_script의 예:

job:
  script:
    - echo "예제 스크립트 섹션."
  after_script:
    - echo "`script` 섹션 완료 후 이 명령을 실행합니다."

추가 세부사항:

after_script에서 지정한 스크립트는 before_script 또는 script 명령과 분리된 새로운 셸에서 실행됩니다. 그 결과, 이들은:

현재 작업 디렉터리가 기본값으로 다시 설정됩니다(에 따라 러너가 Git 요청을 처리하는 방법을 정의하는 변수).
before_script 또는 script에 정의한 명령으로 수행한 변경 사항에 접근할 수 없습니다.
- script 스크립트에서 정의된 커맨드 별칭 및 변수.
- 작업 트리 외부의 변경(러너 실행기에 따라 다름), 예를 들어 before_script 또는 script 스크립트에 의해 설치된 소프트웨어.
별도의 타임아웃을 가집니다. GitLab Runner 16.4 이상에서는 기본값이 5분이며, RUNNER_AFTER_SCRIPT_TIMEOUT 변수를 통해 구성할 수 있습니다. GitLab 16.3 및 이전에서는 타임아웃이 5분으로 하드코딩되어 있습니다.
작업의 종료 코드에 영향을 미치지 않습니다. script 섹션이 성공하고 after_script가 타임아웃되거나 실패하면 작업은 코드 0(Job Succeeded)로 종료됩니다.
CI/CD 작업 토큰을 after_script와 함께 사용할 때 알려진 문제가 있습니다. after_script 명령에서 인증용 작업 토큰을 사용할 수 있지만, 작업이 취소되면 토큰이 즉시 무효화됩니다. 자세한 사항은 문서를 참조하세요.

작업이 타임아웃되면 after_script 명령은 실행되지 않습니다. 문제가 존재합니다 타임아웃된 작업에 대한 after_script 명령 실행을 추가하는 것입니다.

관련 주제:

default와 함께 after_script 사용하여 모든 작업 후 실행해야 하는 기본 명령 배열을 정의합니다.
작업이 취소된 경우 after_script 명령을 건너뛸 수 있도록 설정합니다.
비제로 종료 코드를 무시할 수 있습니다.
after_script와 함께 색상 코드 사용하여 작업 로그를 더 쉽게 검토할 수 있습니다.
사용자 정의 접을 수 있는 섹션 만들기로 작업 로그 출력을 간소화합니다.

`allow_failure`

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

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

작업이 실패할 수 있도록 허용되는 경우(allow_failure: true), 주황색 경고 ()가 표시되어 작업이 실패했음을 나타냅니다. 그러나 파이프라인은 성공적이며 관련 커밋은 경고 없이 통과로 표시됩니다.

이와 같은 경고는 다음과 같은 경우에 표시됩니다:

해당 단계의 모든 다른 작업이 성공적인 경우.
파이프라인의 모든 다른 작업이 성공적인 경우.

allow_failure의 기본값은 다음과 같습니다:

수동 작업에 대해 true.
rules 내에서 when: manual을 사용하는 작업에 대해 false.
다른 모든 경우에 대해 false.

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

가능한 입력:

true 또는 false.

allow_failure의 예:

job1:
  stage: test
  script:
    - execute_script_1

job2:
  stage: test
  script:
    - execute_script_2
  allow_failure: true

job3:
  stage: deploy
  script:
    - deploy_to_staging
  environment: staging

이 예에서 job1과 job2는 병렬로 실행됩니다:

job1이 실패하면 deploy 단계의 작업이 시작되지 않습니다.
job2가 실패하면 deploy 단계의 작업이 여전히 시작될 수 있습니다.

추가 세부정보:

allow_failure를 rules의 하위 키로 사용할 수 있습니다.
allow_failure: true가 설정된 경우, 작업은 항상 성공한 것으로 간주되며, 이후 작업은 이 작업이 실패할 경우 when: on_failure에 따라 시작되지 않습니다.
수동 작업에 allow_failure: false를 사용하여 차단 수동 작업을 생성할 수 있습니다. 차단된 파이프라인은 수동 작업이 시작되고 성공적으로 완료될 때까지 나중 단계의 작업을 실행하지 않습니다.

`allow_failure:exit_codes`

allow_failure:exit_codes를 사용하여 작업이 언제 실패할 수 있는지를 제어합니다. 지정된 종료 코드 중 하나에 대해 작업은 allow_failure: true이며, 다른 종료 코드에 대해서는 allow_failure: false입니다.

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

가능한 입력:

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

allow_failure의 예:

test_job_1:
  script:
    - echo "종료 코드 1이 발생하는 스크립트를 실행합니다. 이 작업은 실패합니다."
    - exit 1
  allow_failure:
    exit_codes: 137

test_job_2:
  script:
    - echo "종료 코드 137이 발생하는 스크립트를 실행합니다. 이 작업은 실패할 수 있습니다."
    - exit 137
  allow_failure:
    exit_codes:
      - 137
      - 255

`artifacts`

artifacts를 사용하여 작업 아티팩트로 저장할 파일을 지정합니다.

작업 아티팩트는 작업이 성공, 실패 또는 항상할 때 작업에 첨부되는 파일 및 디렉터리 목록입니다.

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

기본적으로, 나중 단계의 작업은 이전 단계의 작업이 생성한 모든 아티팩트를 자동으로 다운로드합니다. 작업의 아티팩트 다운로드 동작은 dependencies로 제어할 수 있습니다.

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

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

아티팩트에 대해 더 알아보세요.

`artifacts:paths`

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

키워드 유형: 작업 키워드입니다. 작업의 일부로만 사용할 수 있으며, default 섹션에서도 사용 가능합니다.

가능한 입력:

프로젝트 디렉토리에 상대적인 파일 경로 배열입니다.
glob 패턴을 사용하는 와일드카드를 사용할 수 있으며:
- GitLab Runner 13.0 이상에서는 doublestar.Glob을 사용할 수 있습니다.
- GitLab Runner 12.10 이하에서는 filepath.Match을 사용할 수 있습니다.

CI/CD 변수 를 지원합니다.

artifacts:paths 예제:

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

이 예시는 .config와 binaries 디렉토리의 모든 파일이 포함된 아카이브를 생성합니다.

추가 세부정보:

artifacts:name과 함께 사용되지 않을 경우, 아카이브 파일의 이름은 artifacts로 설정되며, 다운로드 시 artifacts.zip이 됩니다.

관련 항목:

특정 작업이 아카이브를 가져오는 작업을 제한하려면 dependencies를 참조하세요.
작업 아카이브 생성을 참고하세요.

`artifacts:exclude`

artifacts:exclude를 사용하여 아티팩트 아카이브에 파일을 추가하지 않도록 방지할 수 있습니다.

키워드 유형: 작업 키워드입니다. 작업의 일부로만 사용할 수 있으며, default 섹션에서도 사용 가능합니다.

가능한 입력:

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

artifacts:exclude 예제:

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

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

추가 세부정보:

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

관련 항목:

작업 아카이브에서 파일 제외을 참조하세요.

`artifacts:expire_in`

expire_in을 사용하여 작업 아카이브가 저장되는 기간을 지정하고 기한이 만료되면 삭제됩니다. expire_in 설정은 다음에 영향을 미치지 않습니다:

최신 작업의 아카이브는, 최신 작업 아카이브 유지가 프로젝트 수준 또는 인스턴스 전체에서 비활성화되지 않는 한 영향을 미치지 않습니다.

만료된 후, 아카이브는 기본적으로 매시간 삭제되며(크론 작업 사용), 더 이상 접근할 수 없습니다.

키워드 유형: 작업 키워드입니다. 작업의 일부로만 사용할 수 있으며, 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에 업로드되고 저장될 때 시작됩니다. 만료 시간이 정의되지 않으면, 기본적으로는 인스턴스 전체 설정에 따릅니다.
만료 날짜를 덮어쓰고 아카이브가 자동으로 삭제되지 않도록 보호하려면:
- 작업 페이지에서 유지를 선택합니다.
- expire_in의 값을 never로 설정합니다.
만료 시간이 너무 짧으면, 긴 파이프라인의 후속 단계에서 작업이 이전 작업에서 만료된 아카이브를 가져오려고 할 수 있습니다. 아카이브가 만료된 경우, 이를 가져오려고 하는 작업은 필요한 아카이브를 가져올 수 없습니다 오류를 발생시킵니다. 만료 시간을 더 길게 설정하거나 후속 작업에서 dependencies를 사용하여 만료된 아카이브를 가져오려고 하지 않도록 합니다.

`artifacts:expose_as`

artifacts:expose_as 키워드를 사용하여
병합 요청 UI에서 작업 아티팩트를 노출합니다.

키워드 유형: 작업 키워드. 작업의 일부로만 사용하거나
default 섹션에서 사용할 수 있습니다.

가능한 입력:

아티팩트 다운로드 링크에 표시할 이름입니다.
반드시 artifacts:paths와 함께 사용해야 합니다.

artifacts:expose_as의 예:

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

추가 세부정보:

아티팩트는 저장되지만 UI에 표시되지 않습니다. artifacts:paths 값이 다음과 같은 경우:
- CI/CD 변수를 사용합니다.
- 디렉토리를 정의하지만 /로 끝나지 않습니다. 예를 들어, directory/는 artifacts:expose_as와 함께 작동하지만, directory는 작동하지 않습니다.
- ./로 시작합니다. 예를 들어, file는 artifacts:expose_as와 함께 작동하지만, ./file은 작동하지 않습니다.
병합 요청당 최대 10개의 작업 아티팩트를 노출할 수 있습니다.
Glob 패턴은 지원되지 않습니다.
디렉토리가 지정되고, 디렉토리에 파일이 여러 개 있는 경우,
링크는 작업 아티팩트 브라우저로 연결됩니다.
GitLab Pages가 활성화된 경우, GitLab은
아티팩트가 다음 확장명을 가진 단일 파일인 경우 자동으로 아티팩트를 렌더링합니다:
- .html 또는 .htm
- .txt
- .json
- .xml
- .log

관련 주제:

병합 요청 UI에서 작업 아티팩트 노출.

`artifacts:name`

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

정의하지 않으면 기본 이름은 artifacts이며, 다운로드할 때 artifacts.zip이 됩니다.

키워드 유형: 작업 키워드. 작업의 일부로만 사용하거나
default 섹션에서 사용할 수 있습니다.

가능한 입력:

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

artifacts:name의 예:

현재 작업의 이름으로 아카이브를 생성합니다:

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 제거됨.

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

artifacts:public를 사용하여 작업 아티팩트가 공개적으로 사용 가능한지 여부를 결정합니다.

artifacts:public가 true(기본값)인 경우,
공개 파이프라인의 아티팩트는 익명, 게스트 및 리포터 사용자가 다운로드할 수 있습니다.

공개 파이프라인에서 익명, 게스트 및 리포터 사용자가
아티팩트에 대한 읽기 액세스를 거부하려면 artifacts:public를 false로 설정합니다:

키워드 유형: 작업 키워드. 작업의 일부로만 사용하거나
default 섹션에서 사용할 수 있습니다.

가능한 입력:

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

artifacts:public의 예:

job:
  artifacts:
    public: false

`artifacts:access`

도입됨 GitLab 16.11에서.

artifacts:access를 사용하여 작업 아티팩트에 누가 액세스할 수 있는지 결정합니다.

artifacts:public와 artifacts:access를 같은 작업에서 사용할 수 없습니다.

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

가능한 입력:

all (기본값): 공개 파이프라인의 작업에 있는 아티팩트는 익명, 게스트 및 리포터 사용자 포함 누구나 다운로드할 수 있습니다.
developer: 작업의 아티팩트는 Developer 역할 이상의 사용자만 다운로드할 수 있습니다.
none: 작업의 아티팩트는 누구에게도 다운로드할 수 없습니다.

artifacts:access 예제:

job:
  artifacts:
    access: 'developer'

추가 세부정보:

artifacts:access는 모든 artifacts:reports에도 영향을 미칩니다,
따라서 보고서를 위한 아티팩트의 액세스를 제한할 수도 있습니다.

`artifacts:reports`

artifacts:reports를 사용하여
작업의 포함된 템플릿에 의해 생성된 아티팩트를 수집합니다.

키워드 유형: 작업 키워드. 작업의 일부로만 사용하거나
default 섹션에서 사용할 수 있습니다.

가능한 입력:

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

artifacts:reports 예제:

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

추가 세부정보:

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

`artifacts:untracked`

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

키워드 유형: 작업 키워드. 작업의 일부로만 사용하거나
default 섹션에서 사용할 수 있습니다.

가능한 입력:

true 또는 false (정의하지 않으면 기본값).

artifacts:untracked 예제:

모든 Git 추적되지 않은 파일을 저장합니다:

job:
  artifacts:
    untracked: true

관련 주제:

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

`artifacts:when`

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

키워드 유형: 작업 키워드. 작업의 일부로만 사용하거나
default 섹션에서 사용할 수 있습니다.

가능한 입력:

on_success (기본값): 작업이 성공할 때만 아티팩트를 업로드합니다.
on_failure: 작업이 실패할 때만 아티팩트를 업로드합니다.
always: 항상 아티팩트를 업로드합니다 (작업이 타임아웃될 때를 제외하고).
예를 들어, 아티팩트를 업로드할 때 필요한 경우입니다.

artifacts:when 예제:

job:
  artifacts:
    when: on_failure

추가 세부정보:

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

`before_script`

before_script를 사용하여 각 작업의 script 명령 전에 실행되어야 하는 명령 배열을 정의합니다. 이는 artifacts가 복원된 후에 실행됩니다.

키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있거나 default 섹션에서 사용할 수 있습니다.

가능한 입력: 다음을 포함하는 배열:

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

before_script 예시:

job:
  before_script:
    - echo "이 명령은 모든 'script:' 명령 이전에 실행됩니다."
  script:
    - echo "이 명령은 작업의 'before_script' 명령 이후에 실행됩니다."

추가 세부정보:

before_script에 지정한 스크립트는 기본 script에서 지정한 스크립트와 결합됩니다. 결합된 스크립트는 하나의 쉘에서 함께 실행됩니다.
최상위에서 before_script를 사용하되 default 섹션에 포함되지 않은 것은 사용되지 않도록 권장됩니다.

관련 주제:

default와 함께 before_script 사용하기 정의 모든 작업의 script 명령 전에 실행되어야 하는 기본 명령 배열을 정의합니다.
비제로 종료 코드 무시하기.
before_script와 함께 색상 코드 사용하기 작업 로그 검토를 쉽게 만들기 위해.
사용자 정의 접을 수 있는 섹션 만들기 작업 로그 출력을 단순화합니다.

`cache`

도입됨 GitLab 15.0에서, 캐시는 보호된 브랜치와 비보호 브랜치 간에 공유되지 않습니다.

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

캐시는 다음과 같습니다:

파이프라인 및 작업 간에 공유됩니다.
기본적으로 보호된 브랜치와 비보호 브랜치 간에 공유되지 않습니다.
artifacts 이전에 복원됩니다.
최대 네 개의 다양한 캐시로 제한됩니다.

특정 작업에 대해 캐싱 비활성화를 할 수 있으며, 예를 들어 다음을 재정의할 수 있습니다:

default로 정의된 기본 캐시.
include로 추가된 작업의 구성.

캐시에 대한 더 많은 정보는 GitLab CI/CD의 캐싱을 참조하세요.

`cache:paths`

cache:paths 키워드를 사용하여 어떤 파일이나 디렉터리를 캐시할지 선택합니다.

키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있거나 default 섹션에서 사용할 수 있습니다.

가능한 입력:

프로젝트 디렉터리($CI_PROJECT_DIR)에 상대적인 경로 배열. 다음과 같은 와일드카드를 사용할 수 있습니다:
- GitLab Runner 13.0 이상에서는 doublestar.Glob.
- GitLab Runner 12.10 이하에서는 filepath.Match.

cache:paths 예시:

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

rspec:
  script:
    - echo "이 작업은 캐시를 사용합니다."
  cache:
    key: binaries-cache
    paths:
      - binaries/*.apk
      - .config

추가 세부정보:

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

관련 주제:

캐시의 일반적인 사용 사례를 참조하여 cache:paths 예제를 확인하세요.

`cache:key`

cache:key 키워드를 사용하여 각 캐시에 고유한 식별 키를 부여합니다. 같은 캐시 키를 사용하는 모든 작업은 서로 다른 파이프라인에서도 동일한 캐시를 사용합니다.

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

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

키워드 유형: 작업 키워드. 작업의 일부로만 사용하거나 default 섹션에서 사용할 수 있습니다.

가능한 입력:

문자열.
미리 정의된 CI/CD 변수.
둘의 조합.

cache:key 예시:

cache-job:
  script:
    - echo "이 작업은 캐시를 사용합니다."
  cache:
    key: binaries-cache-$CI_COMMIT_REF_SLUG
    paths:
      - binaries/

추가 세부정보:

Windows Batch를 사용하여 셸 스크립트를 실행하는 경우 $를 %로 바꿔야 합니다. 예: key: %CI_COMMIT_REF_SLUG%
cache:key 값에는 다음이 포함될 수 없습니다:
- / 문자, 또는 해당 URI 인코딩된 %2F.
- 오직 . 문자 (아무 개수), 또는 해당 URI 인코딩된 %2E.
캐시는 작업 간에 공유되므로 서로 다른 작업에 서로 다른 경로를 사용하는 경우에도 다른 cache:key를 설정해야 합니다. 그렇지 않으면 캐시 내용이 덮어씌워질 수 있습니다.

관련 주제:

지정된 cache:key를 찾을 수 없는 경우 사용할 대체 캐시 키를 지정할 수 있습니다.
단일 작업에서 여러 캐시 키를 사용할 수 있습니다.
더 많은 cache:key 예제를 보려면 일반 cache 사용 사례를 참조하세요.

`cache:key:files`

cache:key:files 키워드를 사용하여 특정 파일이 하나 또는 두 개 변경될 때 새로운 키를 생성합니다. cache:key:files를 사용하면 일부 캐시를 재사용하고 덜 자주 재구성할 수 있어 이후의 파이프라인 실행 속도가 빨라집니다.

키워드 유형: 작업 키워드. 작업의 일부로만 사용하거나 default 섹션에서 사용할 수 있습니다.

가능한 입력:

하나 또는 두 개의 파일 경로 배열.

CI/CD 변수는 지원되지 않습니다.

cache:key:files 예시:

cache-job:
  script:
    - echo "이 작업은 캐시를 사용합니다."
  cache:
    key:
      files:
        - Gemfile.lock
        - package.json
    paths:
      - vendor/ruby
      - node_modules

이 예시는 Ruby 및 Node.js 의존성을 위한 캐시를 생성합니다. 캐시는 현재 버전의 Gemfile.lock 및 package.json 파일에 연결되어 있습니다. 이 파일 중 하나가 변경되면 새로운 캐시 키가 계산되고 새로운 캐시가 생성됩니다. 이후 동일한 Gemfile.lock 및 package.json을 사용하는 작업 실행은 cache:key:files로 새로운 캐시를 사용하며, 의존성을 다시 빌드하지 않습니다.

추가 세부정보:

캐시 key는 나열된 각 파일을 변경한 가장 최근 커밋에서 계산된 SHA입니다. 두 파일 모두 어떤 커밋에서도 변경되지 않았다면 대체 키는 default입니다.

`cache:key:prefix`

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

키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있거나 default 섹션에서 사용할 수 있습니다.

가능한 입력:

문자열
미리 정의된 변수
두 가지의 조합.

cache:key:prefix의 예:

rspec:
  script:
    - echo "이 rspec 작업은 캐시를 사용합니다."
  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`

untracked: true를 사용하여 Git 저장소에서 추적되지 않은 모든 파일을 캐시합니다.

추적되지 않은 파일에는 다음이 포함됩니다:

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

추적되지 않은 파일을 캐시하면 작업이 다운로드할 때 예기치 않게 큰 캐시를 생성할 수 있습니다:

일반적으로 추적되지 않는 의존성, 예를 들어 gems 또는 node 모듈과 같은 것들.
다른 작업에서 아티팩트를 가져옵니다. 아티팩트에서 추출된 파일은 기본적으로 추적되지 않습니다.

키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있거나 default 섹션에서 사용할 수 있습니다.

가능한 입력:

true 또는 false (기본값).

cache:untracked의 예:

rspec:
  script: test
  cache:
    untracked: true

추가 세부정보:

cache:untracked를 cache:paths와 결합하여 모든 추적되지 않은 파일과 구성된 경로의 파일을 캐시할 수 있습니다. cache:paths는 특정 파일, 추적된 파일 또는 작업 디렉토리 외부의 파일을 캐시하는 데 사용하고, cache:untracked는 모든 추적되지 않은 파일을 캐시합니다. 예를 들어:
```
rspec:
  script: test
  cache:
    untracked: true
    paths:
      - binaries/
```
이 예제에서 작업은 저장소의 모든 추적되지 않은 파일과 binaries/의 모든 파일을 캐시합니다. binaries/에 추적되지 않은 파일이 있다면, 두 키워드 모두에 의해 커버됩니다.

`cache:unprotect`

GitLab 15.8에서 도입됨.

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

경고: true로 설정하면 보호된 브랜치에 접근할 수 없는 사용자가 보호된 브랜치에서 사용되는 캐시 키를 읽고 쓸 수 있습니다.

키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있거나 default 섹션에서 사용할 수 있습니다.

가능한 입력:

true 또는 false (기본값).

cache:unprotect의 예:

rspec:
  script: test
  cache:
    unprotect: true

`cache:when`

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

cache: paths와 함께 사용해야 하며, 그렇지 않으면 캐시가 저장되지 않습니다.

키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있으며, default 섹션에서도 사용할 수 있습니다.

가능한 입력:

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

cache:when의 예:

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

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

`cache:policy`

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

작업이 시작될 때만 캐시를 다운로드하고, 작업이 종료될 때는 변경 사항을 절대 업로드하지 않도록 하려면 cache:policy:pull을 사용하세요.

작업이 종료될 때만 캐시를 업로드하고, 작업이 시작될 때는 절대 캐시를 다운로드하지 않도록 하려면 cache:policy:push를 사용하세요.

동일한 캐시를 사용하는 많은 작업이 병렬로 실행될 때는 pull 정책을 사용하세요. 이 정책은 작업 실행 속도를 높이고 캐시 서버의 부하를 줄입니다. 캐시를 빌드하기 위해 push 정책을 가진 작업을 사용할 수 있습니다.

cache: paths와 함께 사용해야 하며, 그렇지 않으면 캐시가 저장되지 않습니다.

키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있으며, default 섹션에서도 사용할 수 있습니다.

가능한 입력:

pull
push
pull-push (기본값)
CI/CD 변수.

cache:policy의 예:

prepare-dependencies-job:
  stage: build
  cache:
    key: gems
    paths:
      - vendor/bundle
    policy: push
  script:
    - echo "이 작업은 의존성만 다운로드하고 캐시를 빌드합니다."
    - echo "의존성을 다운로드하고 있습니다..."

faster-test-job:
  stage: test
  cache:
    key: gems
    paths:
      - vendor/bundle
    policy: pull
  script:
    - echo "이 작업 스크립트는 캐시를 사용하지만 업데이트하지 않습니다."
    - echo "테스트를 실행하는 중입니다..."

관련 주제:

변수를 사용하여 작업의 캐시 정책을 제어할 수 있습니다.

`cache:fallback_keys`

cache:fallback_keys를 사용하여 cache:key에 대한 캐시가 없을 경우 복원하려고 시도할 키의 목록을 지정합니다. 캐시는 fallback_keys 섹션에 지정된 순서로 검색됩니다.

키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있으며, default 섹션에서도 사용할 수 있습니다.

가능한 입력:

캐시 키 배열

cache:fallback_keys의 예:

rspec:
  script: rspec
  cache:
    key: gems-$CI_COMMIT_REF_SLUG
    paths:
      - rspec/
    fallback_keys:
      - gems
    when: 'always'

`coverage`

coverage를 사용하여 사용자 정의 정규 표현식으로 코드 커버리지를 추출하는 방법을 구성합니다. 작업 출력에서 정규 표현식과 일치하는 문장이 하나라도 있으면 UI에 커버리지 정보가 표시됩니다.

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

가능한 입력:

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

coverage의 예:

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

이 예에서는:

GitLab이 작업 로그에서 정규 표현식과 일치하는 부분을 확인합니다. Code coverage: 67.89% of lines covered와 같은 줄이 일치할 것입니다.
GitLab은 그러면 일치된 조각에서 \d+(?:\.\d+)?와 일치하는지 확인합니다. 위의 샘플 일치 줄은 67.89라는 코드 커버리지를 제공합니다.

추가 세부정보:

정규 표현식 예제는 Code Coverage에서 확인할 수 있습니다.
작업 출력에 일치하는 줄이 여러 개인 경우, 마지막 줄이 사용됩니다 (역 검색의 첫 번째 결과).
단일 줄에서 여러 개의 일치 항목이 있을 경우, 마지막 일치 항목에서 커버리지 숫자가 검색됩니다.
일치된 조각에서 여러 개의 커버리지 숫자가 발견된 경우, 첫 번째 숫자가 사용됩니다.
선행 제로는 제거됩니다.
하위 파이프라인에서의 커버리지 출력은 기록되거나 표시되지 않습니다. 더 많은 세부정보는 관련 문제를 확인하세요.

`dast_configuration`

Tier: Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

dast_configuration 키워드를 사용하여 CI/CD 구성에서 사용할 사이트 프로필과 스캐너 프로필을 지정합니다. 두 프로필 모두 프로젝트에서 먼저 생성되어야 합니다. 작업의 단계는 dast이어야 합니다.

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

가능한 입력: site_profile 및 scanner_profile 각각 하나씩.

site_profile을 사용하여 작업에서 사용할 사이트 프로필을 지정합니다.
scanner_profile을 사용하여 작업에서 사용할 스캐너 프로필을 지정합니다.

dast_configuration의 예:

stages:
  - build
  - dast

include:
  - template: DAST.gitlab-ci.yml

dast:
  dast_configuration:
    site_profile: "Example Co"
    scanner_profile: "Quick Passive Test"

이 예에서 dast 작업은 include 키워드로 추가된 dast 구성을 확장하여 특정 사이트 프로필과 스캐너 프로필을 선택합니다.

추가 세부정보:

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

관련 주제:

`dependencies`

dependencies 키워드를 사용하여 특정 작업의 목록을 정의하고 artifacts 을 가져옵니다.

지정된 작업은 모두 이전 단계에 있어야 합니다.

작업을 아예 아티팩트를 다운로드하지 않도록 설정할 수도 있습니다.

dependencies가 작업에 정의되지 않으면 이전 단계의 모든 작업이 종속성으로 간주되며, 작업은 해당 작업의 모든 아티팩트를 가져옵니다.

키워드 유형: 작업 키워드. 작업의 일부분으로만 사용할 수 있습니다.

가능한 입력:

아티팩트를 가져올 작업의 이름.
빈 배열([]), 작업이 아티팩트를 다운로드하지 않도록 구성합니다.

dependencies 예제:

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

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

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

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

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

이 예제에서 두 개의 작업이 아티팩트를 갖습니다: build osx 및 build linux.

test osx가 실행될 때, build osx의 아티팩트가 다운로드되어 빌드의 컨텍스트 내에서 추출됩니다.

test linux의 경우에도 같은 일이 일어나며 build linux의 아티팩트가 사용됩니다.

deploy 작업은 이전 모든 작업의 아티팩트를 다운로드합니다. stage 우선순위 때문입니다.

추가 세부 정보:

작업 상태는 중요하지 않습니다. 작업이 실패하거나 수동 작업으로 트리거되지 않더라도 오류가 발생하지 않습니다.
종속 작업의 아티팩트가 만료되거나 삭제되면 작업이 실패합니다.
동일한 단계의 작업에서 아티팩트를 가져오려면 needs:artifacts를 사용해야 합니다.

작업 내에서 dependencies와 needs를 결합하지 않아야 합니다.

`environment`

environment를 사용하여 작업이 배포되는 환경을 정의합니다.

키워드 유형: 작업 키워드. 작업의 일부분으로만 사용할 수 있습니다.

가능한 입력: 작업이 배포되는 환경의 이름은 다음 형식 중 하나입니다:

일반 텍스트, 문자, 숫자, 공백 및 다음 문자: -, _, /, $, {, }.
CI/CD 변수, 사전 정의된, 프로젝트, 그룹, 인스턴스 또는 .gitlab-ci.yml 파일에서 정의된 변수.

script 섹션에서 정의된 변수를 사용할 수 없습니다.

environment 예제:

deploy to production:
  stage: deploy
  script: git push production HEAD:main
  environment: production

추가 세부 정보:

environment를 지정하고 해당 이름의 환경이 존재하지 않으면 환경이 생성됩니다.

`environment:name`

환경의 이름을 설정합니다.

일반적인 환경 이름은 qa, staging, production이지만, 아무 이름이나 사용할 수 있습니다.

키워드 유형: 작업 키워드. 작업의 일부분으로만 사용할 수 있습니다.

가능한 입력: 작업이 배포되는 환경의 이름은 다음 형식 중 하나입니다:

일반 텍스트, 문자, 숫자, 공백 및 다음 문자: -, _, /, $, {, }.
CI/CD 변수, 사전 정의된, 프로젝트, 그룹, 인스턴스 또는 .gitlab-ci.yml 파일에서 정의된 변수.

script 섹션에서 정의된 변수를 사용할 수 없습니다.

environment:name 예제:

deploy to production:
  stage: deploy
  script: git push production HEAD:main
  environment:
    name: production

`environment:url`

환경에 대한 URL을 설정합니다. 환경입니다.

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

가능한 입력: 다음 형식 중 하나의 단일 URL:

https://prod.example.com과 같은 일반 텍스트.
CI/CD 변수, 미리 정의된 변수, 프로젝트, 그룹, 인스턴스 또는 .gitlab-ci.yml 파일에 정의된 변수. script 섹션에 정의된 변수를 사용할 수 없습니다.

environment:url 예시:

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

추가 세부정보:

작업이 완료된 후에, 병합 요청, 환경 또는 배포 페이지에서 버튼을 선택하여 URL에 접근할 수 있습니다.

`environment:on_stop`

환경을 종료(중지)하는 것은 environment 아래에 정의된 on_stop 키워드를 통해 수행할 수 있습니다. 이는 환경을 종료하기 위해 실행되는 다른 작업을 선언합니다.

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

추가 세부정보:

더 많은 세부정보와 예시는 environment:action을 참조하세요.

`environment:action`

action 키워드를 사용하여 작업이 환경과 상호작용하는 방식을 지정합니다.

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

가능한 입력: 다음 키워드 중 하나:

값	설명
`start`	기본값. 작업이 환경을 시작함을 나타냅니다. 작업이 시작된 후 배포가 생성됩니다.
`prepare`	작업이 환경을 준비만 함을 나타냅니다. 배포를 트리거하지 않습니다. 환경 준비에 대해 더 읽기.
`stop`	작업이 환경을 중지함을 나타냅니다. 환경 중지에 대해 더 읽기.
`verify`	작업이 환경을 검증만 함을 나타냅니다. 배포를 트리거하지 않습니다. 환경 검증에 대해 더 읽기.
`access`	작업이 환경에 접근만 함을 나타냅니다. 배포를 트리거하지 않습니다. 환경 접근에 대해 더 읽기.

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에서 도입되었습니다.

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

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

가능한 입력: 자연어로 작성된 기간. 예를 들어, 다음은 모두 동등합니다:

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`

kubernetes 키워드를 사용하여 프로젝트와 연결된 Kubernetes 클러스터에 배포를 구성합니다.

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

environment:kubernetes 예시:

deploy:
  stage: deploy
  script: make deploy-app
  environment:
    name: production
    kubernetes:
      namespace: production

이 구성은 배포 작업을 설정하여 production 환경에 배포하며, production Kubernetes 네임스페이스를 사용합니다.

추가 세부정보:

Kubernetes 구성은 GitLab이 관리하는 Kubernetes 클러스터에는 지원되지 않습니다. managed by GitLab.

관련 주제:

kubernetes에 대한 사용 가능한 설정.

`environment:deployment_tier`

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

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

가능한 입력: 다음 중 하나:

production
staging
testing
development
other

environment:deployment_tier 예시:

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

추가 세부정보:

이 작업 정의에서 생성된 환경은 이 값에 따라 티어가 할당됩니다.
기존 환경은 나중에 이 값을 추가하더라도 티어가 업데이트되지 않습니다. 기존 환경은 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 작업은 review/$CI_COMMIT_REF_SLUG 환경을 동적으로 생성하는 배포로 표시됩니다.

$CI_COMMIT_REF_SLUG는 러너에 의해 설정된 CI/CD 변수입니다.

$CI_ENVIRONMENT_SLUG 변수는 환경 이름에 기반하지만, URL에 포함하기 적합한 형식입니다.

deploy as review app 작업이 pow라는 이름의 브랜치에서 실행될 경우, 이 환경은 https://review-pow.example.com/와 같은 URL로 접근할 수 있습니다.

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

`extends`

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

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

가능한 입력:

파이프라인 내 다른 작업의 이름입니다.
파이프라인 내 다른 작업의 이름 목록(배열)입니다.

extends 예시:

.tests:
  script: rake test
  stage: test
  only:
    refs:
      - branches

rspec:
  extends: .tests
  script: rake rspec
  only:
    variables:
      - $RSPEC

이 예에서 rspec 작업은 .tests 템플릿 작업의 구성을 사용합니다.

파이프라인을 생성할 때 GitLab은:

키를 기준으로 역 깊이 병합을 수행합니다.
.tests의 내용을 rspec 작업과 병합합니다.
키의 값은 병합하지 않습니다.

결과적으로 이 rspec 작업은 다음과 같습니다:

rspec:
  script: rake rspec
  stage: test
  only:
    refs:
      - branches
    variables:
      - $RSPEC

추가 세부정보:

extends에 대해 여러 부모를 사용할 수 있습니다.
extends 키워드는 최대 11단계의 상속을 지원하지만, 3단계를 초과하여 사용하는 것은 피해야 합니다.
위의 예에서 .tests는 숨겨진 작업이며, 일반 작업의 구성에서도 확장할 수 있습니다.

관련 주제:

`hooks`

도입됨 GitLab 15.6에서 ci_hooks_pre_get_sources_script라는 플래그와 함께. 기본적으로 비활성화되어 있습니다.

일반 제공 GitLab 15.10에서. 기능 플래그 ci_hooks_pre_get_sources_script가 제거되었습니다.

hooks를 사용하여 특정 작업 실행 단계에서 실행할 명령 목록을 지정합니다. 예를 들어 Git 리포지토리를 가져오기 전에 사용할 수 있습니다.

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

가능한 입력:

후크와 해당 명령의 해시. 사용 가능한 후크: pre_get_sources_script.

`hooks:pre_get_sources_script`

도입됨 GitLab 15.6에서 ci_hooks_pre_get_sources_script라는 플래그와 함께. 기본적으로 비활성화되어 있습니다.

일반 제공 GitLab 15.10에서. 기능 플래그 ci_hooks_pre_get_sources_script가 제거되었습니다.

hooks:pre_get_sources_script를 사용하여 Git 리포지토리 및 모든 하위 모듈을 클론하기 전에 실행할 명령 목록을 지정합니다.

예를 들어 다음을 위해 사용할 수 있습니다:

가능한 입력: 다음을 포함하는 배열:

CI/CD 변수는 지원됨.

hooks:pre_get_sources_script의 예:

job1:
  hooks:
    pre_get_sources_script:
      - echo 'hello job1 pre_get_sources_script'
  script: echo 'hello job1 script'

관련 주제:

GitLab Runner 구성

`identity`

세부정보: Tier: Free, Premium, Ultimate Offering: GitLab.com
Status: Beta

도입됨 GitLab 16.9에서 google_cloud_support_feature_flag라는 플래그와 함께. 이 기능은 베타입니다.

GitLab.com에서 활성화됨 GitLab 17.1에서. 기능 플래그 google_cloud_support_feature_flag가 제거되었습니다.

이 기능은 베타입니다.

identity를 사용하여 아이덴티티 연합을 통해 타사 서비스에 인증합니다.

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

가능한 입력: 식별자. 지원되는 제공자:

google_cloud: Google Cloud. Google Cloud IAM 통합으로 구성해야 합니다.

identity의 예:

job_with_workload_identity:
  identity: google_cloud
  script:
    - gcloud compute instances list

관련 주제:

`id_tokens`

History

Introduced in GitLab 15.7.

id_tokens를 사용하여 타사 서비스와 인증하기 위한 JSON 웹 토큰(JWT)를 생성합니다. 이렇게 생성된 모든 JWT는 OIDC 인증을 지원합니다. 필수 aud 하위 키워드는 JWT의 aud 클레임을 구성하는 데 사용됩니다.

가능한 입력:

aud 클레임이 있는 토큰 이름. aud는 다음을 지원합니다:
- 단일 문자열.
- 문자열 배열.
- CI/CD 변수.

id_tokens의 예:

job_with_id_tokens:
  id_tokens:
    ID_TOKEN_1:
      aud: https://vault.example.com
    ID_TOKEN_2:
      aud:
        - https://gcp.com
        - https://aws.com
    SIGSTORE_ID_TOKEN:
      aud: sigstore
  script:
    - command_to_authenticate_with_vault $ID_TOKEN_1
    - command_to_authenticate_with_aws $ID_TOKEN_2
    - command_to_authenticate_with_gcp $ID_TOKEN_2

관련 주제:

`image`

image를 사용하여 작업이 실행될 Docker 이미지를 지정합니다.

키워드 유형: Job 키워드. 작업의 일부로만 사용하거나 default 섹션에서 사용할 수 있습니다.

가능한 입력: 필요시 레지스트리 경로를 포함하여 이미지의 이름을 다음 형식 중 하나로 지정합니다:

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

CI/CD 변수 지원됨.

image의 예:

default:
  image: ruby:3.0

rspec:
  script: bundle exec rspec

rspec 2.7:
  image: registry.example.com/my-group/my-project/ruby:2.7
  script: bundle exec rspec

이 예에서 ruby:3.0 이미지는 파이프라인의 모든 작업에 대한 기본값입니다.

rspec 2.7 작업은 기본값을 사용하지 않으며, 작업별 image 섹션으로 기본값을 덮어씁니다.

관련 주제:

Docker 컨테이너에서 CI/CD 작업 실행하기.

`image:name`

작업이 실행될 Docker 이미지의 이름. 혼자 사용된 image와 유사합니다.

키워드 유형: Job 키워드. 작업의 일부로만 사용하거나 default 섹션에서 사용할 수 있습니다.

가능한 입력: 필요시 레지스트리 경로를 포함하여 이미지의 이름을 다음 형식 중 하나로 지정합니다:

<image-name> (<image-name>을 latest 태그와 함께 사용하는 것과 동일함)
<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 작업 실행하기.

`image:entrypoint`

컨테이너의 진입점으로 실행할 명령 또는 스크립트입니다.

Docker 컨테이너가 생성될 때, entrypoint는 Docker --entrypoint 옵션으로 변환됩니다.

구문은 Dockerfile ENTRYPOINT 지시어와 유사하며, 각 셸 토큰은 배열의 별도 문자열입니다.

키워드 유형: 작업 키워드. 작업의 일부로만 사용하거나 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를 사용하여 GitLab Runner의 Docker 실행자에 옵션을 전달합니다.

키워드 유형: 작업 키워드. 작업의 일부로만 사용하거나 default 섹션에서 작성할 수 있습니다.

가능한 입력:

Docker 실행자를 위한 옵션의 해시, 여기에는 다음이 포함될 수 있습니다:

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:pull_policy`

소개됨 GitLab 15.1에서 기능 플래그로 ci_docker_image_pull_policy라는 이름으로. 기본적으로 비활성화되어 있습니다.

GitLab.com 및 자체 관리에서 활성화됨 GitLab 15.2에서.

일반적으로 사용 가능 GitLab 15.4에서. 기능 플래그 ci_docker_image_pull_policy 제거됨.

GitLab Runner 15.1 이상이 필요합니다.

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

키워드 유형: 작업 키워드. 작업의 일부로만 사용하거나 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]

추가 세부정보:

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

관련 주제:

`inherit`

inherit를 사용하여 기본 키워드 및 변수의 상속을 제어하세요.

`inherit:default`

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

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

가능한 입력:

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

inherit:default의 예:

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

job1:
  script: echo "이 작업은 기본 키워드를 상속하지 않습니다."
  inherit:
    default: false

job2:
  script: echo "이 작업은 나열된 두 개의 기본 키워드만 상속합니다. 'interruptible'은 상속하지 않습니다."
  inherit:
    default:
      - retry
      - image

추가 세부사항:

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

`inherit:variables`

inherit:variables를 사용하여 전역 변수 키워드의 상속을 제어하세요.

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

가능한 입력:

모든 전역 변수의 상속을 활성화하거나 비활성화하기 위한 true (기본값) 또는 false.
상속할 특정 변수 목록.

inherit:variables의 예:

variables:
  VARIABLE1: "이것은 변수 1입니다."
  VARIABLE2: "이것은 변수 2입니다."
  VARIABLE3: "이것은 변수 3입니다."

job1:
  script: echo "이 작업은 전역 변수를 상속하지 않습니다."
  inherit:
    variables: false

job2:
  script: echo "이 작업은 나열된 두 개의 전역 변수만 상속합니다. 'VARIABLE3'은 상속하지 않습니다."
  inherit:
    variables:
      - VARIABLE1
      - VARIABLE2

추가 세부사항:

상속할 전역 변수를 한 줄로 나열할 수도 있습니다: variables: [VARIABLE1, VARIABLE2]

`interruptible`

trigger 작업에 대한 지원 도입됨 GitLab 16.8에서.

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

중복 파이프라인 자동 취소 기능의 동작은 workflow:auto_cancel:on_new_commit 설정에 의해 제어됩니다.

키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있거나 default 섹션에서 사용할 수 있습니다.

가능한 입력:

true 또는 false (기본값).

기본 동작으로서의 interruptible 예:

workflow:
  auto_cancel:
    on_new_commit: conservative # 기본 동작

stages:
  - stage1
  - stage2
  - stage3

step-1:
  stage: stage1
  script:
    - echo "취소될 수 있습니다."
  interruptible: true

step-2:
  stage: stage2
  script:
    - echo "취소될 수 없습니다."

step-3:
  stage: stage3
  script:
    - echo "step-2가 취소될 수 없기 때문에 이 단계는 절대 취소될 수 없습니다. 비록 interruptible로 설정되어 있더라도."
  interruptible: true

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

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

auto_cancel:on_new_commit:interruptible 설정으로서의 interruptible 예:

workflow:
  auto_cancel:
    on_new_commit: interruptible

stages:
  - stage1
  - stage2
  - stage3

step-1:
  stage: stage1
  script:
    - echo "취소될 수 있습니다."
  interruptible: true

step-2:
  stage: stage2
  script:
    - echo "취소될 수 없습니다."

step-3:
  stage: stage3
  script:
    - echo "취소될 수 있습니다."
  interruptible: true

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

추가 세부사항:

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

`needs`

needs를 사용하여 작업을 비순차적으로 실행할 수 있습니다. needs를 사용하는 작업 간의 관계는 유향 비순환 그래프로 시각화할 수 있습니다.

단계 순서를 무시하고 다른 작업이 완료될 때까지 기다리지 않고 일부 작업을 실행할 수 있습니다.

여러 단계의 작업이 동시에 실행될 수 있습니다.

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

가능한 입력:

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

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 작업은 build 단계가 완료될 때까지 기다리지 않고 즉시 실행됩니다 (needs: []이기 때문에).
리눅스 경로: linux:rspec 작업은 linux:build 작업이 끝나는 즉시 실행됩니다.
macOS 경로: mac:rspec 작업은 mac:build 작업이 끝나는 즉시 실행됩니다.
production 작업은 모든 이전 작업이 완료되면 실행됩니다: lint, linux:build, linux:rspec, mac:build, mac:rspec.

추가 세부정보:

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

`needs:artifacts`

작업이 needs를 사용할 때, 기본적으로 이전 단계의 모든 아티팩트를 다운로드하지 않습니다.

needs가 있는 작업은 이전 단계가 완료되기 전에 시작할 수 있기 때문입니다.

needs를 사용하면 needs 구성에 나열된 작업에서만 아티팩트를 다운로드할 수 있습니다.

작업에서 아티팩트를 언제 다운로드할지 제어하려면 artifacts: true(기본값) 또는 artifacts: false를 사용하세요.

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

가능한 입력값:

true (기본값) 또는 false.

needs:artifacts의 예:

test-job1:
  stage: test
  needs:
    - job: build_job1
      artifacts: true

test-job2:
  stage: test
  needs:
    - job: build_job2
      artifacts: false

test-job3:
  needs:
    - job: build_job1
      artifacts: true
    - job: build_job2
    - build_job3

이 예제에서:

test-job1 작업은 build_job1 아티팩트를 다운로드합니다.
test-job2 작업은 build_job2 아티팩트를 다운로드하지 않습니다.
test-job3 작업은 세 개의 build_jobs에서 아티팩트를 다운로드합니다. 왜냐하면 모든 세 개의 필요 작업에서 artifacts가 true이거나 기본값인 true이기 때문입니다.

추가 세부사항:

동일한 작업에서 needs를 dependencies와 결합해서는 안 됩니다.

`needs:project`

Tier: Premium, Ultimate

Offering: GitLab.com, Self-managed, GitLab Dedicated

needs:project를 사용하여 다른 파이프라인에서 최대 다섯 개의 작업의 아티팩트를 다운로드할 수 있습니다.

아티팩트는 지정된 참조에 대해 지정된 작업의 최신 성공적인 실행에서 다운로드됩니다.

여러 작업을 지정하려면 각 작업을 needs 키워드 아래의 별도 배열 항목으로 추가하세요.

지정된 참조에 대한 파이프라인이 실행 중인 경우, needs:project가 있는 작업은 파이프라인이 완료될 때까지 기다리지 않습니다.

대신, 지정된 작업의 최신 성공적으로 실행된 버전에서 아티팩트를 다운로드합니다.

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

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

가능한 입력값:

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

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를 현재 프로젝트와 동일하게 설정하되, 현재 파이프라인과 다른 참조를 사용하세요.

동일한 참조에서 실행 중인 동시 파이프라인이 아티팩트를 덮어쓸 수 있습니다.

파이프라인을 실행하는 사용자는 그룹 또는 프로젝트에 대해 최소한 Reporter 역할을 가져야 하며, 그룹/프로젝트는 공개 가시성을 가져야 합니다.
trigger와 동일한 작업에서 needs:project를 사용할 수 없습니다.
다른 파이프라인에서 아티팩트를 다운로드하기 위해 needs:project를 사용할 때는 필요 작업이 완료될 때까지 기다리지 않습니다. 작업이 완료되기를 기다리기 위해 needs 사용하기는 동일한 파이프라인의 작업으로 제한됩니다.

필요한 작업이 다른 파이프라인에서 완료되기 전에 그 작업이 아티팩트를 다운로드하려고 시도하지 않도록 하세요.

parallel에서 실행되는 작업의 아티팩트를 다운로드할 수 없습니다.
project, job, 및 ref에서 CI/CD 변수를 지원합니다.

관련 주제:

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

`needs:pipeline:job`

자식 파이프라인은 부모 파이프라인의 작업이나 동일한 부모-자식 파이프라인 계층의 다른 자식 파이프라인에서 아티팩트를 다운로드할 수 있습니다.

키워드 종류: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.

가능한 입력:

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

needs:pipeline:job의 예:

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

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

child-pipeline:
  stage: test
  trigger:
    include: child.yml
    strategy: depend
  variables:
    PARENT_PIPELINE_ID: $CI_PIPELINE_ID

자식 파이프라인(child.yml):

use-artifact:
  script: cat artifact.txt
  needs:
    - pipeline: $PARENT_PIPELINE_ID
      job: create-artifact

이 예에서는 부모 파이프라인의 create-artifact 작업이 일부 아티팩트를 생성합니다. child-pipeline 작업은 자식 파이프라인을 트리거하며, CI_PIPELINE_ID 변수를 PARENT_PIPELINE_ID 변수로 자식 파이프라인에 전달합니다. 자식 파이프라인은 그 변수를 needs:pipeline에서 사용하여 부모 파이프라인에서 아티팩트를 다운로드할 수 있습니다.

추가 세부 사항:

pipeline 속성은 현재 파이프라인 ID($CI_PIPELINE_ID)를 허용하지 않습니다. 현재 파이프라인의 작업에서 아티팩트를 다운로드하려면 needs:artifacts를 사용하세요.
trigger job에서 needs:pipeline:job을 사용할 수 없거나 다중 프로젝트 파이프라인에서 아티팩트를 가져오는 데 사용할 수 없습니다. 다중 프로젝트 파이프라인에서 아티팩트를 가져오려면 needs:project를 사용하세요.

`needs:optional`

파이프라인에 가끔 존재하지 않는 작업이 필요할 경우 needs 구성에 optional: true를 추가하세요. 정의되지 않은 경우 기본값은 optional: false입니다.

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

needs 항목에 optional: true가 있고 필요한 작업이 파이프라인에 존재하는 경우, 작업은 해당 작업이 완료될 때까지 기다립니다.
필요한 작업이 존재하지 않으면, 다른 모든 needs 요구사항이 충족되면 작업이 시작될 수 있습니다.
needs 섹션에 선택적 작업만 포함되어 있고, 파이프라인에 추가된 작업이 없으면, 작업이 즉시 시작됩니다(빈 needs 항목과 동일: needs: []).
필요한 작업에 optional: false가 있지만 파이프라인에 추가되지 않은 경우, 파이프라인 시작 시 ‘job1’ 작업이 ‘job2’ 작업을 필요로 하지만 파이프라인에 추가되지 않았다는 에러와 함께 실패합니다.

키워드 종류: 작업 키워드. 작업의 일부로만 사용할 수 있습니다.

needs:optional의 예:

build-job:
  stage: build

test-job1:
  stage: test

test-job2:
  stage: test
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

deploy-job:
  stage: deploy
  needs:
    - job: test-job2
      optional: true
    - job: test-job1
  environment: production

review-job:
  stage: deploy
  needs:
    - job: test-job2
      optional: true
  environment: review

이 예에서는:

build-job, test-job1 및 test-job2가 단계 순서에 따라 시작됩니다.
기본 브랜치인 경우 test-job2가 파이프라인에 추가되며, 따라서:
- deploy-job은 test-job1과 test-job2가 완료될 때까지 기다립니다.
- review-job은 test-job2의 완료를 기다립니다.
기본 브랜치가 아니면, test-job2가 파이프라인에 추가되지 않으므로:
- deploy-job은 오직 test-job1이 완료되기를 기다리고 누락된 test-job2를 기다리지 않습니다.
- review-job은 필요한 작업이 없고 즉시 시작됩니다(마치 build-job과 동시에 시작하는 것처럼), needs: [] 와 같습니다.

`needs:pipeline`

업스트림 파이프라인에서 작업으로 파이프라인 상태를 미러링하려면 needs:pipeline 키워드를 사용하세요.

기본 브랜치의 최신 파이프라인 상태가 작업으로 복제됩니다.

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

가능한 입력:

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

needs:pipeline 예시:

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

추가 세부정보:

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

`needs:parallel:matrix`

GitLab 16.3에서 소개됨.

작업은 단일 파이프라인 내에서 다중 인스턴스를 가지고 서로 다른 변수 값으로 작업을 여러 번 실행하기 위해 parallel:matrix를 사용할 수 있습니다.

needs:parallel:matrix를 사용하여 병렬화된 작업에 따라 작업을 비순차적으로 실행합니다.

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

가능한 입력: 변수의 해시 배열:

변수 및 값은 parallel:matrix 작업에서 정의된 변수 및 값 중에서 선택해야 합니다.

needs:parallel:matrix 예시:

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

위 예시는 다음과 같은 작업을 생성합니다:

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

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

관련 주제:

여러 병렬 작업과 함께 needs를 사용하여 병렬화된 작업 지정하기.

추가 세부정보:

needs:parallel:matrix의 매트릭스 변수 순서는 필요한 작업의 매트릭스 변수 순서와 일치해야 합니다. 예를 들어, 이전 예제의 linux:rspec 작업에서 변수의 순서를 반대로 하는 것은 유효하지 않습니다:

linux:rspec:
  stage: test
  needs:
    - job: linux:build
      parallel:
        matrix:
          - STACK: app1        # 변수 순서가 `linux:build`와 일치하지 않으며 유효하지 않습니다.
            PROVIDER: aws
  script: echo "Running rspec on linux..."

`pages`

pages를 사용하여 GitLab Pages 작업을 정의하고 정적 콘텐츠를 GitLab에 업로드합니다. 그런 다음 콘텐츠는 웹사이트로 게시됩니다.

다음 작업을 수행해야 합니다:

artifacts를 정의하여 콘텐츠 디렉터리의 경로를 지정해야 하며, 기본적으로 public입니다.
다른 콘텐츠 디렉터리를 사용하려면 publish를 사용해야 합니다.

키워드 유형: 작업 이름.

pages 예시:

pages:
  stage: deploy
  script:
    - mv my-html-content public
  artifacts:
    paths:
      - public
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  environment: production

이 예시는 my-html-content/ 디렉터리를 public/으로 이름을 바꿉니다.

이 디렉터리는 아티팩트로 내보내지고 GitLab Pages로 게시됩니다.

`pages:publish`

GitLab 16.1에 도입됨.

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

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

가능한 입력: Pages 콘텐츠가 포함된 디렉토리에 대한 경로.

publish의 예:

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

이 예제는 Eleventy를 사용하여 정적 웹사이트를 생성하고

생성된 HTML 파일을 dist/ 디렉토리에 출력합니다. 이 디렉토리는 아티팩트로 내보내지고 GitLab Pages로 게시됩니다.

`pages:pages.path_prefix`

Tier: Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated
Status: Beta

GitLab 16.7에 도입됨 플래그가 있는 실험으로써, 기본값으로 비활성화됨.

GitLab.com, self-managed 및 GitLab Dedicated에서 활성화됨 GitLab 17.4에서.

이 기능의 가용성은 기능 플래그에 의해 제어됩니다.
자세한 내용은 이력을 참조하세요.
이 기능은 테스트 용도로 사용 가능하지만, 프로덕션 사용을 위해 준비되지 않았습니다.

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

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

가능한 입력: 문자열, CI/CD 변수, 또는 둘의 조합. 주어진 값은 소문자로 변환되고, 63바이트로 단축되며, 영숫자 문자를 제외한 모든 문자는 하이픈으로 대체됩니다. 앞뒤 하이픈은 허용되지 않습니다.

pages.path_prefix의 예:

pages:
  stage: deploy
  script:
    - echo "Pages accessible through ${CI_PAGES_URL}/${CI_COMMIT_BRANCH}"
  pages:
    path_prefix: "$CI_COMMIT_BRANCH"
  artifacts:
    paths:
    - public

이 예제에서는 각 브랜치에 대해 다른 페이지 배포가 생성됩니다.

`pages:pages.expire_in`

Tier: Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

GitLab 17.4에 도입됨

expire_in을 사용하여 배포가 만료되기 전에 얼마나 오래 사용할 수 있을지를 지정합니다.
배포가 만료된 후에는 10분마다 실행되는 크론 작업에 의해 비활성화됩니다.

추가 배포는 기본적으로 만료됩니다.
만료되지 않도록 하려면 값을 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

pages:pages.expire_in의 예:

pages:
  stage: deploy
  script:
    - echo "Pages accessible through ${CI_PAGES_URL}"
  pages:
    expire_in: 1 week
  artifacts:
    paths:
      - public

`parallel`

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

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

여러 런너가 존재해야 하며, 또는 단일 런너가 여러 작업을 동시에 실행하도록 구성되어야 합니다.

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

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

가능한 입력:

1에서 200 사이의 숫자 값.

parallel의 예:

test:
  script: rspec
  parallel: 5

이 예제는 병렬로 실행되는 5개의 작업을 생성하며, 이름은 test 1/5에서 test 5/5까지입니다.

추가 세부 정보:

모든 병렬 작업에는 CI_NODE_INDEX 및 CI_NODE_TOTAL 미리 정의된 CI/CD 변수가 설정됩니다.
parallel을 사용하는 작업이 포함된 파이프라인은 다음을 수행할 수 있습니다:
- 사용 가능한 런너보다 더 많은 병렬로 실행되는 작업을 생성합니다. 초과 작업은 대기 중으로 표시되며 사용 가능한 런너를 기다리는 동안 pending 상태로 대기합니다.
- 너무 많은 작업을 생성하고 파이프라인이 job_activity_limit_exceeded 오류로 실패합니다. 활성 파이프라인에서 존재할 수 있는 최대 작업 수는 인스턴스 수준에서 제한됩니다.

관련 주제:

대규모 작업을 병렬로 처리하기.

`parallel:matrix`

GitLab 15.9에 도입됨, 최대 허용 변형 수가 50에서 200으로 증가했습니다.

parallel:matrix를 사용하여 단일 파이프라인에서 여러 번 작업을 병렬로 실행하지만, 각 작업 인스턴스에 대해 서로 다른 변수 값을 사용합니다.

여러 런너가 존재해야 하며, 또는 단일 런너가 여러 작업을 동시에 실행하도록 구성되어야 합니다.

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

가능한 입력: 변수의 해시 배열:

변수 이름은 오직 숫자, 문자 및 밑줄(_)만 사용할 수 있습니다.
값은 문자열 또는 문자열 배열이어야 합니다.
변형 수는 200을 초과할 수 없습니다.

parallel:matrix의 예:

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

이 예제는 서로 다른 값으로 PROVIDER와 STACK을 가지는 10개의 병렬 deploystacks 작업을 생성합니다:

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

추가 세부 정보:

parallel:matrix 작업은 작업 이름에 변수 값을 추가하여 서로 다른 작업을 구별하지만, 대형 값은 이름이 한계를 초과할 수 있습니다:
- 작업 이름은 255자 이하여야 합니다.
- needs를 사용할 경우, 작업 이름은 128자 이하이어야 합니다.
동일한 변수 값으로 서로 다른 변수 이름을 갖는 여러 행렬 구성을 생성할 수 없습니다. 작업 이름은 변수 값에서 생성되므로, 동일한 값을 가진 행렬 항목은 서로 동일한 작업 이름을 생성하여 서로 덮어쓰게 됩니다.

예를 들어, 이 test 구성은 두 개의 동일한 작업 시리즈를 생성하려고 하지만, OS2 버전이 OS 버전을 덮어씁니다:
```
test:
  parallel:
    matrix:
      - OS: [ubuntu]
        PROVIDER: [aws, gcp]
      - OS2: [ubuntu]
        PROVIDER: [aws, gcp]
```
- parallel:matrix와 함께 !reference 태그를 사용할 때 알려진 문제가 있습니다.

관련 주제:

`release`

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

릴리스 작업은 release-cli에 접근할 수 있어야 하며, 이 도구는 $PATH에 있어야 합니다.

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

Shell executor 또는 유사한 것을 사용하는 경우, 실행기가 등록된 서버에 release-cli를 설치하세요.

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

가능한 입력: release 하위 키:

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

release 키워드의 예:

release_job:
  stage: release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  rules:
    - if: $CI_COMMIT_TAG                  # 태그가 수동으로 생성될 때 이 작업 실행
  script:
    - echo "릴리스 작업 실행 중."
  release:
    tag_name: $CI_COMMIT_TAG
    name: '릴리스 $CI_COMMIT_TAG'
    description: 'release-cli를 사용하여 생성된 릴리스입니다.'

이 예제는 릴리스를 생성합니다:

Git 태그를 푸시할 때.
Code > Tags에서 UI에 Git 태그를 추가할 때.

추가 세부 사항:

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

관련 주제:

`release:tag_name`

필수. 릴리스에 대한 Git 태그입니다.

태그가 프로젝트에 아직 존재하지 않는 경우, 릴리스와 동시에 생성됩니다.

새 태그는 파이프라인과 연결된 SHA를 사용합니다.

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

가능한 입력:

태그 이름.

CI/CD 변수 지원됨.

release:tag_name의 예:

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

$CI_COMMIT_TAG CI/CD 변수를 tag_name으로 사용하세요.
새로운 태그에 대해서만 작업이 실행되도록 rules:if를 사용하세요.

job:
  script: echo "새 태그에 대한 릴리스 작업 실행 중."
  release:
    tag_name: $CI_COMMIT_TAG
    description: '릴리스 설명'
  rules:
    - if: $CI_COMMIT_TAG

릴리스와 새 태그를 동시에 생성하려면, rules가 새 태그에 대해서만 작업이 실행되도록 구성되어서는 안 됩니다. 의미 버전 관리 예:

job:
  script: echo "릴리스 작업을 실행하고 새 태그를 생성 중."
  release:
    tag_name: ${MAJOR}_${MINOR}_${REVISION}
    description: '릴리스 설명'
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"

`release:tag_message`

GitLab 15.3에서 도입됨. release-cli v0.12.0 이상에서 지원됩니다.

태그가 존재하지 않으면, 새로 생성된 태그는 tag_message로 지정된 메시지로 주석이 달립니다.

생략할 경우, 경량 태그가 생성됩니다.

키워드 유형: 작업 키워드. 작업의 일부분으로만 사용할 수 있습니다.

가능한 입력:

텍스트 문자열.

release:tag_message의 예:

  release_job:
    stage: release
    release:
      tag_name: $CI_COMMIT_TAG
      description: '릴리스 설명'
      tag_message: '주석이 달린 태그 메시지'

`release:name`

릴리스 이름. 생략할 경우, release: tag_name의 값으로 채워집니다.

키워드 유형: 작업 키워드. 작업의 일부분으로만 사용할 수 있습니다.

가능한 입력:

텍스트 문자열.

release:name의 예:

  release_job:
    stage: release
    release:
      name: '릴리스 $CI_COMMIT_TAG'

`release:description`

릴리스의 긴 설명입니다.

키워드 유형: 작업 키워드. 작업의 일부분으로만 사용할 수 있습니다.

가능한 입력:

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

release:description의 예:

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

추가 세부사항:

description은 release-cli를 실행하는 쉘에 의해 평가됩니다. CI/CD 변수를 사용하여 설명을 정의할 수 있지만, 일부 쉘은 변수를 참조하는 다른 구문을 사용할 수 있습니다. 유사하게, 일부 쉘에서는 특별한 문자가 이스케이프 될 필요가 있을 수 있습니다.

예를 들어, 백틱(`)은 역슬래시(\)로 이스케이프 되어야 할 수 있습니다.

`release:ref`

릴리스에 대한 ref, 만약 release: tag_name이 아직 존재하지 않는 경우.

키워드 유형: 작업 키워드. 작업의 일부분으로만 사용할 수 있습니다.

가능한 입력:

커밋 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-cli 버전 v0.4.0 이상이 필요합니다.

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' # 선택 사항
      link_type: 'other' # 선택 사항

`resource_group`

resource_group를 사용하여 리소스 그룹을 생성하여

동일 프로젝트의 서로 다른 파이프라인에서 작업이 상호 배제되도록 합니다.

예를 들어, 동일한 리소스 그룹에 속하는 여러 작업이 동시에 대기열에 있으면,

오직 하나의 작업만 시작됩니다. 다른 작업들은 resource_group이 무료가 될 때까지 기다립니다.

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

배포 선호도에 따라 작업 동시성을 전략적으로 제어하기 위해 프로세스 모드를 선택할 수 있습니다.

기본 프로세스 모드는 unordered입니다. 리소스 그룹의 프로세스 모드를 변경하려면,

API를 사용하여 기존 리소스 그룹을 편집하는 요청을 보내십시오.

환경당 여러 리소스 그룹을 정의할 수 있습니다. 예를 들어,

물리적인 장치에 배포할 때 여러 물리적인 장치가 있을 수 있습니다. 각 장치는 배포할 수 있지만,

주어진 시간에 장치당 하나의 배포만 발생할 수 있습니다.

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

가능한 입력:

문자, 숫자, -, _, /, $, {, }, ., 및 공백만 가능합니다. /로 시작하거나 끝날 수 없습니다. CI/CD 변수 지원됨.

resource_group 예시:

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

이 예제에서 두 개의 deploy-to-production 작업은 두 개의 별도 파이프라인에서 동시에 실행될 수 없습니다.

따라서, 동시에 프로덕션 환경에 배포가 발생하지 않도록 보장할 수 있습니다.

관련 주제:

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

`retry`

retry를 사용하여 작업이 실패할 경우 몇 번 재시도할지를 구성합니다.

정의되지 않은 경우 기본값은 0이며 작업은 재시도하지 않습니다.

작업이 실패하면, 작업은 최대 두 번 더 처리되며, 성공하거나 최대 재시도 수에 도달할 때까지 처리됩니다.

기본적으로 모든 실패 유형은 작업 재시도를 유발합니다. 실패 시 어떤 재시도를 선택할지 결정하기 위해

retry:when 또는 retry:exit_codes를 사용하십시오.

키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다 또는 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와 함께 사용하여 특정 실패 경우에 대해서만 작업을 재시도합니다.

retry:max는 최대 재시도 수로, retry와 같으며 0, 1, 또는 2가 될 수 있습니다.

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

가능한 입력:

단일 실패 유형 또는 하나 이상의 실패 유형의 배열:

always: 모든 실패 시 재시도 (기본값).
unknown_failure: 실패 원인이 불명확한 경우 재시도.
script_failure: 다음을 포함하여 실패 시 재시도:
- 스크립트가 실패함.
- 러너가 Docker 이미지를 가져오지 못함. docker, docker+machine, kubernetes 실행자에 해당.
api_failure: API 실패 시 재시도.
stuck_or_timeout_failure: 작업이 멈추거나 시간 초과된 경우 재시도.
runner_system_failure: 러너 시스템 오류가 발생한 경우 재시도 (예: 작업 설정 실패).
runner_unsupported: 러너가 지원되지 않는 경우 재시도.
stale_schedule: 지연된 작업이 실행되지 못한 경우 재시도.
job_execution_timeout: 스크립트가 작업에 대해 설정된 최대 실행 시간을 초과한 경우 재시도.
archived_failure: 작업이 보관되고 실행할 수 없는 경우 재시도.
unmet_prerequisites: 작업이 필수 작업을 완료하지 못한 경우 재시도.
scheduler_failure: 스케줄러가 작업을 러너에 할당하지 못한 경우 재시도.
data_integrity_failure:未知 작업 문제일 경우 재시도.

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

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

러너 시스템 실패가 아닌 다른 실패가 발생하면 작업은 재시도되지 않습니다.

retry:when 예시 (실패 유형 배열):

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

`retry:exit_codes`

GitLab 16.10에서 도입됨 플래그를 사용하여 ci_retry_on_exit_codes라는 이름으로. 기본적으로 비활성화되어 있습니다.

GitLab.com 및 자체 관리에서 활성화됨 GitLab 16.11에서.

retry:exit_codes를 retry:max와 함께 사용하여 특정 실패 사례에 대해서만 작업을 재시도할 수 있습니다.
retry:max는 재시도의 최대 횟수로, retry와 같이
0, 1 또는 2가 될 수 있습니다.

키워드 유형: 작업 키워드. 작업의 일부로만 사용하거나
default 섹션에서 사용할 수 있습니다.

가능한 입력:

하나의 종료 코드.
종료 코드 배열.

retry:exit_codes 예제:

test_job_1:
  script:
    - echo "종료 코드 1을 생성하는 스크립트를 실행합니다. 이 작업은 재시도되지 않습니다."
    - exit 1
  retry:
    max: 2
    exit_codes: 137

test_job_2:
  script:
    - echo "종료 코드 137을 생성하는 스크립트를 실행합니다. 이 작업은 재시도됩니다."
    - exit 137
  retry:
    max: 1
    exit_codes:
      - 255
      - 137

관련 주제:

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

`rules`

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

규칙은 파이프라인이 생성될 때 평가되며, 차례로 평가됩니다.
일치하는 항목이 발견되면 더 이상 규칙이 확인되지 않고 작업이 구성에 따라 파이프라인에 포함되거나 제외됩니다.
일치하는 규칙이 없으면 작업이 파이프라인에 추가되지 않습니다.

rules는 규칙 배열을 허용합니다. 각 규칙은 최소한 하나의 항목이 있어야 합니다:

if
changes
exists
when

규칙은 또한 선택적으로 다음과 결합될 수 있습니다:

allow_failure
needs
variables
interruptible

여러 키워드를 결합하여 복잡한 규칙을 만들 수 있습니다.

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

if, changes 또는 exists 규칙이 일치하고 when: on_success로 구성된 경우 (정의되지 않은 경우 기본값)
when: delayed, 또는 when: always.
when: on_success, when: delayed, 또는 when: always인 규칙이 도달했을 경우.

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

일치하는 규칙이 없는 경우.
규칙이 일치하지만 when: never인 경우.

추가 예제는 규칙을 사용하여 작업이 실행되는 시기 지정을 참조하십시오.

`rules:if`

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

if 문이 true인 경우 작업을 파이프라인에 추가합니다.
if 문이 true이지만 when: never와 결합된 경우, 작업을 파이프라인에 추가하지 않습니다.
if 문이 false인 경우 다음 rules 항목을 확인합니다 (다른 항목이 존재하는 경우).

if 절은 다음에 따라 평가됩니다:

CI/CD 변수 또는 미리 정의된 CI/CD 변수의 값에 따라
일부 예외와 함께.
차례로, rules 실행 흐름을 따릅니다.

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

가능한 입력:

CI/CD 변수 표현식.

rules:if 예제:

job:
  script: echo "안녕하세요, 규칙!"
  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이 정의되지 않은 경우, 해당 규칙은 작업의 when을 사용합니다.
이 경우 정의되지 않은 경우 기본값으로 on_success가 설정됩니다.
작업 수준의 when과 규칙 내의 when을 혼합할 수 있습니다.
규칙의 when 구성이 작업 수준의 when보다 우선합니다.
script 섹션의 변수와는 달리, 규칙 표현식의 변수는 항상 $VARIABLE 형식으로 표시됩니다.
다른 구성 파일을 조건부로 포함하기 위해 rules:if를 사용할 수 있습니다.
=~ 및 !~ 표현식의 오른쪽에 있는 CI/CD 변수는 정규식으로 평가됩니다.

관련 주제:

`rules:changes`

rules:changes를 사용하여 특정 파일에 대한 변경 사항을 확인하여 언제 작업을 파이프라인에 추가할지를 지정합니다.

새로운 브랜치 파이프라인이거나 Git push 이벤트가 없는 경우, rules: changes는 항상 true로 평가되며 작업이 항상 실행됩니다. 태그 파이프라인, 예약된 파이프라인 및 수동 파이프라인은 모두 Git push 이벤트와 관련이 없습니다. 이러한 경우를 다루기 위해, rules: changes: compare_to를 사용하여 파이프라인 참조를 비교할 브랜치를 지정하세요.

compare_to를 사용하지 않는 경우, 브랜치 파이프라인 또는 병합 요청 파이프라인과 함께 rules: changes를 사용해야 하지만, 새로운 브랜치를 생성할 때 rules: changes는 여전히 true로 평가됩니다. 사용 시:

병합 요청 파이프라인에서는 rules:changes가 변경 사항을 대상 MR 브랜치와 비교합니다.
브랜치 파이프라인에서는 rules:changes가 변경 사항을 브랜치의 이전 커밋과 비교합니다.

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

가능한 입력:

다음과 같은 항목을 포함하는 배열로 설정할 수 있습니다.

파일 경로. 파일 경로에는 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이 변경된 경우, 작업을 수동 작업으로 파이프라인에 추가하고, 작업이 트리거되지 않아도 파이프라인이 계속 실행됩니다(allow_failure: true).
$DOCKERFILES_DIR/**/*의 파일이 변경된 경우, 작업을 파이프라인에 추가합니다.
나열된 파일이 변경되지 않은 경우, 어떤 작업도 파이프라인에 추가되지 않습니다(같은 의미로 when: never).

추가 세부정보:

glob 패턴은 Ruby의 File.fnmatch로 해석되며 flags File::FNM_PATHNAME | File::FNM_DOTMATCH | File::FNM_EXTGLOB이 적용됩니다.
각 rules:changes 섹션당 최대 50개의 패턴 또는 파일 경로를 정의할 수 있습니다.
changes는 변경된 파일이 하나라도 있을 경우 true로 평가됩니다(OR 연산).
추가 예제는 규칙을 사용하여 작업 실행 조건 지정을 참조하십시오.
$ 문자를 변수와 경로 모두에 사용할 수 있습니다. 예를 들어, $VAR 변수가 존재하면 해당 값이 사용됩니다. 존재하지 않으면 $는 경로의 일부로 해석됩니다.
changes와 함께 중첩 변수를 사용할 수 없습니다. 자세한 내용은 문제 425803를 참조하십시오.

관련 주제:

직원 사용 시 rules: changes에 따라 작업이나 파이프라인이 예기치 않게 실행될 수 있음.

`rules:changes:paths`

GitLab 15.2에서 소개됨.

rules:changes를 사용하여 특정 파일이 변경될 때만 작업이 파이프라인에 추가되도록 지정하고, rules:changes:paths를 사용하여 파일을 지정합니다.

rules:changes:paths는 서브키 없이 rules:changes를 사용하는 것과 같습니다. 모든 추가 세부 사항 및 관련 주제는 동일합니다.

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

가능한 입력:

위의 rules:changes에 대한 가능한 입력을 참조하세요.

rules:changes:paths의 예:

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

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

이 예에서 두 작업 모두 동일한 동작을 합니다.

`rules:changes:compare_to`

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 아래 나열된 파일의 변경 사항에 대해 비교할 참조를 지정합니다.

키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있으며, 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 작업은 Dockerfile이 refs/heads/branch1에 대해 변경된 경우에만 포함되며, 파이프라인 소스는 머지 요청 이벤트입니다.

추가 세부 사항:

병합 결과 파이프라인과 함께 compare_to를 사용하면 예상치 못한 결과가 발생할 수 있습니다. GitLab이 생성하는 내부 커밋이 비교 기준이기 때문입니다.

관련 주제:

브랜치가 비어 있을 경우 작업을 건너뛰는 데 rules:changes:compare_to를 사용할 수 있습니다.

`rules:exists`

CI/CD 변수 지원이 도입됨 GitLab 15.6에서.

exists를 사용하여 특정 파일이 리포지토리에 존재할 때 작업을 실행합니다.

키워드 유형: 작업 키워드. 이를 작업의 일부 또는 include로 사용할 수 있습니다.

가능한 입력:

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

rules:exists의 예:

job:
  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이 존재하면 실행됩니다.

추가 세부 정보:

rules:exists와 함께 사용되는 CI/CD 변수에는 몇 가지 제한 사항이 있습니다:
- exists와 함께 중첩 변수를 사용 할 수 없습니다. 더 자세한 내용은 문제 411344를 참조하세요.
- 경우에 따라 exists와 함께 CI/CD 변수에 / 또는 ./를 사용할 수 없습니다. 자세한 내용은 문제 386595를 참조하세요.
glob 패턴은 루비의 File.fnmatch로 해석되며, 플래그 File::FNM_PATHNAME | File::FNM_DOTMATCH | File::FNM_EXTGLOB가 적용됩니다.
성능상의 이유로 GitLab은 exists 패턴 또는 파일 경로에 대해 최대 10,000회의 검사를 수행합니다. 10,000번째 검사가 지나면 패턴이 있는 glob 규칙은 항상 일치하는 것으로 간주됩니다. 즉, exists 규칙은 10,000개 이상의 파일이 있는 프로젝트에서 항상 일치한다고 가정합니다. 또는 10,000개 미만의 파일이 있지만 exists 규칙이 10,000회 이상 검사된 경우입니다.
- 여러 개의 패턴이 있는 glob이 있는 경우, 한계는 10,000을 glob의 수로 나눈 값입니다. 예를 들어, 4개의 패턴이 있는 규칙은 파일 한계가 2500입니다.
rules:exists 섹션당 최대 50개의 패턴 또는 파일 경로를 정의할 수 있습니다.
exists는 나열된 파일 중 하나라도 발견되면 true로 평가됩니다(OR 연산).
작업 수준의 rules:exists와 함께 GitLab은 파이프라인을 실행하는 프로젝트 및 ref에서 파일을 검색합니다. include와 함께 rules:exists를 사용하는 경우, GitLab은 include 섹션을 포함하는 파일의 프로젝트 및 ref에서 파일을 검색합니다. include 섹션이 포함된 프로젝트는 다음을 사용하는 경우 파이프라인을 실행하는 프로젝트와 다를 수 있습니다:
- 중첩 포함.
- 컴플라이언스 파이프라인.
rules:exists는 산출물의 존재 여부를 검색할 수 없습니다, 왜냐하면 rules 평가는 작업이 실행되기 전에 발생하고 산출물은 가져오기 때문입니다.

`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를 사용하는 것과 동일합니다. 모든 추가 세부정보는 동일합니다.

키워드 유형: 작업 키워드. 작업의 일부 또는 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

이 예에서 두 작업은 동일한 동작을 가집니다.

추가 세부정보:

경우에 따라 exists와 함께 CI/CD 변수에서 / 또는 ./를 사용할 수 없습니다. 문제 386595를 참조하여 자세히 알아보세요.

`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와 함께 사용해야 합니다.

키워드 유형: 작업 키워드. 작업의 일부 또는 include로 사용할 수 있으며, rules:exists:paths와 결합해야 합니다.

가능한 입력:

exists:project: 네임스페이스와 그룹을 포함한 전체 프로젝트 경로.
exists: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 작업은 my-group/my-project 프로젝트의 v1.0.0으로 태그된 커밋에 Dockerfile이 존재할 때만 포함됩니다.

`rules:when`

rules:when을 단독으로 사용하거나 다른 규칙의 일부로 사용하여 작업을 파이프라인에 추가하기 위한 조건을 제어합니다. rules:when은 when과 유사하지만 약간 다른 입력 옵션을 가지고 있습니다.

만약 rules:when 규칙이 if, changes, 또는 exists와 결합되지 않으면, 작업의 규칙을 평가할 때 도달하면 항상 일치합니다.

키워드 유형: 작업 특정. 작업의 일부로만 사용할 수 있습니다.

가능한 입력:

on_success (기본값): 이전 단계의 작업이 실패하지 않을 때에만 작업을 실행합니다.
on_failure: 이전 단계의 작업 중 하나라도 실패할 때에만 작업을 실행합니다.
never: 이전 단계의 작업 상태에 관계없이 작업을 실행하지 않습니다.
always: 이전 단계의 작업 상태에 관계없이 작업을 실행합니다.
manual: 작업을 수동 작업으로 파이프라인에 추가합니다. allow_failure의 기본값이 false로 변경됩니다.
delayed: 작업을 지연 작업으로 파이프라인에 추가합니다.

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: on_success로, 이는 when이 정의되지 않았을 때 기본 동작입니다.
기능 브랜치의 경우 지연 작업으로.
모든 다른 경우에는 수동 작업으로.

추가 세부사항:

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

`rules:allow_failure`

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

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

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

가능한 입력:

true 또는 false. 정의되지 않으면 기본값은 false입니다.

rules:allow_failure의 예:

job:
  script: echo "Hello, Rules!"
  rules:
    - if: $CI_MERGE_REQUEST_TARGET_BRANCH_NAME == $CI_DEFAULT_BRANCH
      when: manual
      allow_failure: true

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

추가 세부사항:

규칙 수준의 rules:allow_failure는 작업 수준의 allow_failure를 오버라이드하며, 특정 규칙이 작업을 트리거할 때만 적용됩니다.

`rules:needs`

GitLab 16.0에서 introduce_rules_with_needs라는 플래그와 함께 도입됨. 기본적으로 비활성화 되어 있음.

GitLab 16.2에서 일반 제공됨. 기능 플래그 introduce_rules_with_needs가 제거됨.

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

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

가능한 입력:

문자열로 된 작업 이름의 배열.
작업 이름과 선택적으로 추가 속성이 포함된 해시.
특정 조건이 충족될 때 작업의 필요성을 없애기 위한 빈 배열([]).

rules:needs 예시:

build-dev:
  stage: build
  rules:
    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH
  script: echo "기능 브랜치이므로 개발 버전을 빌드합니다..."

build-prod:
  stage: build
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  script: echo "기본 브랜치이므로 프로덕션 버전을 빌드합니다..."

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 "기본적으로 개발 스펙을 실행하거나 기본 브랜치일 때 프로덕션 스펙을 실행합니다..."

이 예시에서:

파이프라인이 기본 브랜치가 아닌 브랜치에서 실행되면, 첫 번째 조건과 일치하므로 specs 작업은 build-dev 작업을 필요로 합니다.
파이프라인이 기본 브랜치에서 실행되면, 두 번째 조건과 일치하므로 specs 작업은 build-prod 작업을 필요로 합니다.

추가 세부사항:

규칙의 needs는 작업 수준에서 정의된 needs를 무시합니다. 오버라이드 시, 동작은 작업 수준의 needs와 동일합니다.
규칙의 needs는 artifacts 및 optional을 수용할 수 있습니다.

`rules:variables`

특정 조건을 위한 변수를 정의하기 위해 variables를 규칙에서 사용하세요.

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

가능한 입력:

VARIABLE-NAME: value 형식의 변수 해시.

rules:variables 예시:

job:
  variables:
    DEPLOY_VARIABLE: "default-deploy"
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      variables:                              # 작업 수준에서 정의된 DEPLOY_VARIABLE을 오버라이드
        DEPLOY_VARIABLE: "deploy-production"  # 합니다.
    - if: $CI_COMMIT_REF_NAME =~ /feature/
      variables:
        IS_A_FEATURE: "true"                  # 새로운 변수를 정의합니다.
  script:
    - echo "Run script with $DEPLOY_VARIABLE as an argument"
    - echo "Run another script if $IS_A_FEATURE exists"

`rules:interruptible`

도입됨 GitLab 16.10에서.

특정 조건에 따라 작업의 interruptible 값을 업데이트하기 위해 규칙에서 interruptible을 사용합니다.

키워드 유형: 작업 특정. 작업의 일부로만 사용할 수 있습니다.

가능한 입력:

true 또는 false.

rules:interruptible의 예:

job:
  script: echo "Hello, Rules!"
  interruptible: true
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      interruptible: false  # 작업 수준에서 정의된 interruptible을 무시합니다.
    - when: on_success

추가 세부정보:

규칙 수준의 rules:interruptible은 작업 수준의 interruptible을 무시하며, 특정 규칙이 작업을 트리거할 때만 적용됩니다.

`run`

상태: Experiment

도입됨 GitLab 17.3 플래그 pipeline_run_keyword와 함께. 기본적으로 비활성화됨. GitLab Runner 17.1 필요.

일반적으로 사용 가능 GitLab 17.5. 기능 플래그 pipeline_run_keyword 제거됨.

이 기능의 사용 가능성은 기능 플래그에 의해 제어됩니다.

자세한 내용은 기록을 참조하세요.

이 기능은 테스트용으로 사용할 수 있지만, Production 사용 준비가 되지 않았습니다.

run을 사용하여 작업에서 실행될 일련의 단계를 정의합니다. 각 단계는 스크립트 또는 미리 정의된 단계일 수 있습니다.

선택적 환경 변수와 입력도 제공할 수 있습니다.

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

가능한 입력:

각 해시가 다음 가능한 키를 가진 단계를 나타내는 해시의 배열:
- name: 단계의 이름을 나타내는 문자열.
- script: 실행할 셸 명령을 포함하는 문자열 또는 문자열 배열.
- step: 실행할 미리 정의된 단계를 식별하는 문자열.
- env: 선택적. 이 단계에 특정한 환경 변수의 해시.
- inputs: 선택적. 미리 정의된 단계에 대한 입력 매개변수의 해시.

각 배열 항목은 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'

이 예에서 작업에는 두 개의 단계가 있습니다:

hello_steps는 echo 셸 명령을 실행합니다.
bye_steps는 환경 변수와 입력 매개변수를 사용하는 미리 정의된 단계를 사용합니다.

추가 세부정보:

단계는 script 또는 step 키 중 하나만 가질 수 있으며, 둘 다는 안 됩니다.
run 구성은 기존의 script 키워드와 함께 사용할 수 없습니다.
여러 줄 스크립트는 YAML 블록 스칼라 문법을 사용하여 정의할 수 있습니다.

`script`

script를 사용하여 실행할 명령어를 지정합니다.

트리거 작업을 제외한 모든 작업은 script 키워드가 필요합니다.

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

가능한 입력: 다음을 포함하는 배열:

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

script 예제:

job1:
  script: "bundle exec rspec"

job2:
  script:
    - uname -a
    - bundle exec rspec

추가 세부정보:

script에서 이러한 특수 문자를 사용하면 반드시 단일 인용부호(') 또는 이중 인용부호(")를 사용해야 합니다.

관련 주제:

비제로 종료 코드를 무시할 수 있습니다.
스크립트와 함께 색상 코드를 사용하여 작업 로그를 검토하기 쉽게 만듭니다.
사용자 정의 접이식 섹션을 생성하여 작업 로그 출력을 단순화합니다.

`secrets`

Tier: Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

secrets를 사용하여 다음을 지정합니다:

외부 비밀 공급자에서 검색합니다.
CI/CD 변수로 작업에서 사용 가능합니다 (file 유형 기본값).

`secrets:vault`

GitLab Runner 16.11에서 도입된 generic 엔진 옵션 소개됨.

secrets:vault를 사용하여 HashiCorp Vault에서 제공하는 비밀을 지정합니다.

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

가능한 입력:

engine:name: 비밀 엔진의 이름. kv-v2(기본값), kv-v1 또는 generic 중 하나일 수 있습니다.
engine:path: 비밀 엔진의 경로입니다.
path: 비밀의 경로.
field: 비밀번호가 저장된 필드의 이름.

secrets:vault 예제:

모든 세부정보를 명시적으로 지정하고 KV-V2 비밀 엔진을 사용하려면:

job:
  secrets:
    DATABASE_PASSWORD:  # 이 CI/CD 변수에 비밀 경로를 저장합니다.
      vault:  # 비밀: `ops/data/production/db`, 필드: `password`로 변환됨
        engine:
          name: kv-v2
          path: ops
        path: production/db
        field: password

이 구문을 간소화할 수 있습니다. 단축 구문을 사용할 경우 engine:name과 engine:path는 모두 기본값으로 kv-v2입니다:

job:
  secrets:
    DATABASE_PASSWORD:  # 이 CI/CD 변수에 비밀 경로를 저장합니다.
      vault: production/db/password  # 비밀: `kv-v2/data/production/db`, 필드: `password`로 변환됨

단축 구문에서 사용자 정의 비밀 엔진 경로를 지정하려면 @로 시작하는 접미사를 추가합니다:

job:
  secrets:
    DATABASE_PASSWORD:  # 이 CI/CD 변수에 비밀 경로를 저장합니다.
      vault: production/db/password@ops  # 비밀: `ops/data/production/db`, 필드: `password`로 변환됨

`secrets:gcp_secret_manager`

GitLab 16.8 및 GitLab Runner 16.8에서 도입됨.

secrets:gcp_secret_manager를 사용하여 GCP Secret Manager에서 제공하는 비밀을 지정합니다.

키워드 유형: 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 키워드. 작업의 일부로만 사용할 수 있습니다.

가능한 입력:

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을 사용하여 비밀을 파일 또는 변수 유형 CI/CD 변수로 저장되도록 구성합니다

기본적으로 비밀은 CI/CD 변수의 file 유형으로 작업에 전달됩니다. 비밀의 값은 파일에 저장되며, 변수에는 파일 경로가 포함됩니다.

소프트웨어가 file 유형 CI/CD 변수를 사용할 수 없는 경우 file: false로 설정하여 비밀 값을 변수에 직접 저장합니다.

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

가능한 입력:

true (기본값) 또는 false.

secrets:file의 예:

job:
  secrets:
    DATABASE_PASSWORD:
      vault: production/db/password@ops
      file: false

추가 세부 사항:

file 키워드는 CI/CD 변수의 설정으로, vault 섹션이 아닌 CI/CD 변수 이름 아래에 중첩되어야 합니다.

`secrets:token`

GitLab 15.8에서 도입되었으며, Limit JSON Web Token (JWT) access 설정에 의해 제어됩니다.

항상 사용 가능하게 되었으며 Limit JSON Web Token (JWT) access 설정이 제거되었습니다.

secrets:token을 사용하여 Vault에 인증할 때 사용할 토큰을 명시적으로 선택합니다. 토큰의 CI/CD 변수를 참조하여 선택합니다.

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

가능한 입력:

ID 토큰의 이름

secrets:token의 예:

job:
  id_tokens:
    AWS_TOKEN:
      aud: https://aws.example.com
    VAULT_TOKEN:
      aud: https://vault.example.com
  secrets:
    DB_PASSWORD:
      vault: gitlab/production/db
      token: $VAULT_TOKEN

추가 세부 사항:

token 키워드가 설정되지 않으면 첫 번째 ID 토큰이 인증에 사용됩니다.

`services`

services를 사용하여 스크립트를 실행하는 데 필요한 추가 Docker 이미지를 지정합니다. services 이미지는 image 키워드에 지정된 이미지와 연결됩니다.

키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있거나 default 섹션에서 사용할 수 있습니다.

가능한 입력: 필요할 경우 레지스트리 경로를 포함한 서비스 이미지의 이름은 다음 형식 중 하나입니다:

<image-name> (최신 태그로 <image-name> 사용과 동일)
<image-name>:<tag>
<image-name>@<digest>

CI/CD 변수는 지원됩니다, 그러나 alias에 대해서는 지원되지 않습니다.

services의 예:

default:
  image:
    name: ruby:2.6
    entrypoint: ["/bin/bash"]

  services:
    - name: my-postgres:11.7
      alias: db-postgres
      entrypoint: ["/usr/local/bin/db-postgres"]
      command: ["start"]

  before_script:
    - bundle install

test:
  script:
    - bundle exec rake spec

이 예제에서 GitLab은 작업을 위해 두 개의 컨테이너를 실행합니다:

script 명령을 실행하는 Ruby 컨테이너.
PostgreSQL 컨테이너. Ruby 컨테이너의 script 명령은 db-postgrest 호스트 이름에서 PostgreSQL 데이터베이스에 연결할 수 있습니다.

관련 주제:

`services:docker`

GitLab 16.7에서 도입됨. GitLab Runner 16.7 이상의 버전이 필요합니다.

user 입력 옵션이 GitLab 16.8에서 도입됨.

services:docker를 사용하여 GitLab Runner의 Docker 실행기에 옵션을 전달합니다.

키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있거나 default 섹션에서 사용할 수 있습니다.

가능한 입력:

Docker 실행기에 대한 옵션 해시로, 포함될 수 있는 항목은 다음과 같습니다:

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

services:docker의 예:

arm-sql-job:
  script: echo "서비스 컨테이너에서 sql 테스트 실행"
  image: ruby:2.6
  services:
    - name: super/sql:experimental
      docker:
        platform: arm64/v8
        user: dave

추가 세부사항:

services:docker:platform은 docker pull --platform 옵션에 해당합니다.
services:docker:user는 docker run --user 옵션에 해당합니다.

`services:pull_policy`

GitLab 15.1에서 도입됨 기능 플래그 ci_docker_image_pull_policy와 함께. 기본적으로 비활성화됨.

GitLab.com과 자체 관리에서 활성화됨 GitLab 15.2에서.

GitLab 15.4에서 일반 사용 가능. 기능 플래그 ci_docker_image_pull_policy 제거됨.

GitLab Runner 15.1 이상이 필요합니다.

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

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

가능한 입력:

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

services:pull_policy의 예:

job1:
  script: echo "단일 풀 정책입니다."
  services:
    - name: postgres:11.6
      pull_policy: if-not-present

job2:
  script: echo "여러 개의 풀 정책입니다."
  services:
    - name: postgres:11.6
      pull_policy: [always, if-not-present]

추가 세부정보:

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

관련 주제:

`stage`

stage를 사용하여 작업이 실행되는 단계를 정의합니다. 동일한 stage에 있는 작업은 병렬로 실행할 수 있습니다 (자세한 내용은 추가 세부정보 참조).

stage가 정의되지 않으면 작업은 기본적으로 test 단계를 사용합니다.

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

가능한 입력: 문자열로, 다음 중 하나일 수 있습니다:

기본 단계.
사용자 정의 단계.

stage의 예:

stages:
  - build
  - test
  - deploy

job1:
  stage: build
  script:
    - echo "이 작업은 코드를 컴파일합니다."

job2:
  stage: test
  script:
    - echo "이 작업은 컴파일된 코드를 테스트합니다. 빌드 단계가 완료되면 실행됩니다."

job3:
  script:
    - echo "이 작업도 테스트 단계에서 실행됩니다."

job4:
  stage: deploy
  script:
    - echo "이 작업은 코드를 배포합니다. 테스트 단계가 완료되면 실행됩니다."
  environment: production

추가 세부정보:

작업은 서로 다른 러너에서 실행되는 경우 병렬로 실행될 수 있습니다.
러너가 하나만 있는 경우, 작업은 러너의 concurrent 설정이 1보다 클 경우에 병렬로 실행될 수 있습니다.

`stage: .pre`

.pre 단계는 파이프라인의 시작에서 작업을 실행하기 위해 사용됩니다. .pre는 항상 파이프라인의 첫 번째 단계입니다. 사용자 정의 단계는 .pre 이후에 실행됩니다. stages에서 .pre를 정의할 필요는 없습니다.

파이프라인이 .pre 또는 .post 단계의 작업만 포함하고 있다면 실행되지 않습니다. 다른 단계에서 최소한 하나의 작업이 있어야 합니다.

키워드 유형: 작업의 stage 키워드와 함께만 사용할 수 있습니다.

stage: .pre의 예:

stages:
  - build
  - test

job1:
  stage: build
  script:
    - echo "이 작업은 빌드 단계에서 실행됩니다."

first-job:
  stage: .pre
  script:
    - echo "이 작업은 모든 다른 단계 이전의 .pre 단계에서 실행됩니다."

job2:
  stage: test
  script:
    - echo "이 작업은 테스트 단계에서 실행됩니다."

`stage: .post`

.post 단계는 파이프라인의 끝에서 작업을 실행하기 위해 사용됩니다. .post는 항상 파이프라인의 마지막 단계입니다. 사용자 정의 단계는 .post 이전에 실행됩니다. stages에서 .post를 정의할 필요는 없습니다.

파이프라인이 .pre 또는 .post 단계의 작업만 포함하고 있다면 실행되지 않습니다. 다른 단계에서 최소한 하나의 작업이 있어야 합니다.

키워드 유형: 작업의 stage 키워드와 함께만 사용할 수 있습니다.

stage: .post의 예:

stages:
  - build
  - test

job1:
  stage: build
  script:
    - echo "이 작업은 빌드 단계에서 실행됩니다."

last-job:
  stage: .post
  script:
    - echo "이 작업은 모든 다른 단계 이후의 .post 단계에서 실행됩니다."

job2:
  stage: test
  script:
    - echo "이 작업은 테스트 단계에서 실행됩니다."

추가 세부사항:

파이프라인에 needs: []와 .pre 단계의 작업이 있는 경우, 파이프라인이 생성되는 즉시 모두 시작됩니다. needs: []가 있는 작업은 단계 구성을 무시하고 즉시 시작됩니다.

`tags`

tags를 사용하여 프로젝트에 사용할 수 있는 모든 러너 목록에서 특정 러너를 선택합니다.

러너를 등록할 때, 러너의 태그를 지정할 수 있습니다. 예를 들어 ruby, postgres 또는 development와 같은 태그를 지정할 수 있습니다. 작업을 수행하기 위해서는 러너가 작업에 나열된 모든 태그를 할당받아야 합니다.

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

가능한 입력:

태그 이름의 배열.
CI/CD 변수 지원됨.

tags의 예:

job:
  tags:
    - ruby
    - postgres

이 예에서 ruby와 postgres 태그가 모두 있는 러너만 작업을 실행할 수 있습니다.

추가 세부사항:

태그의 수는 50 미만이어야 합니다.

관련 주제:

`timeout`

timeout을 사용하여 특정 작업에 대한 타임아웃을 구성합니다. 작업이 타임아웃보다 오래 실행되면, 작업이 실패합니다.

작업 수준의 타임아웃은 프로젝트 수준 타임아웃보다 길 수 있지만, 러너의 타임아웃보다 길 수는 없습니다.

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

가능한 입력: 자연어로 작성된 시간의 기간. 예를 들어, 다음은 모두 동등합니다:

3600 seconds
60 minutes
one hour

timeout 예제:

build:
  script: build.sh
  timeout: 3 hours 30 minutes

test:
  script: rspec
  timeout: 3h 30m

`trigger`

environment에 대한 지원이 GitLab 16.4에 도입되었습니다.

trigger를 사용하여 작업이 “트리거 작업”임을 선언하고, 다운스트림 파이프라인을 시작합니다:

트리거 작업은 GitLab CI/CD 구성 키워드의 제한된 세트만 사용할 수 있습니다. 트리거 작업에서 사용할 수 있는 키워드는 다음과 같습니다:

allow_failure.
extends.
needs, 그러나 needs:project은 사용할 수 없습니다.
only and except.
rules.
stage.
trigger.
variables.
when (오직 on_success, on_failure, 또는 always 값과 함께 사용).
resource_group.
environment.

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

가능한 입력:

다중 프로젝트 파이프라인의 경우, 다운스트림 프로젝트로의 경로입니다. CI/CD 변수는 GitLab 15.3 및 이후 버전에서 지원됩니다, 그러나 작업 전용 변수는 지원되지 않습니다. 대신, trigger:project를 사용하세요.
자식 파이프라인의 경우, trigger:include를 사용하세요.

trigger 예제:

trigger-multi-project-pipeline:
  trigger: my-group/my-project

추가 세부정보:

trigger와 동일한 작업에서 when:manual를 사용할 수 있지만, API를 사용하여 when:manual 트리거 작업을 시작할 수는 없습니다. 더 많은 세부정보는 이슈 284086을 참조하세요.
수동 트리거 작업을 실행하기 전에 CI/CD 변수를 수동으로 지정할 수 없습니다.
최상위 variables 섹션(전세계적으로) 또는 트리거 작업 내에서 정의된 CI/CD 변수는 다운스트림 파이프라인에 트리거 변수로 전달됩니다.
파이프라인 변수는 기본적으로 다운스트림 파이프라인에 전달되지 않습니다. 트리거 변수를 다운스트림 파이프라인으로 전달하기 위해 trigger:forward를 사용하세요.
작업 전용 변수는 트리거 작업에서 사용할 수 없습니다.
러너의 config.toml에서 정의된 환경 변수는 트리거 작업에 사용할 수 없으며 다운스트림 파이프라인으로 전달되지 않습니다.
트리거 작업에서 needs:pipeline:job을 사용할 수 없습니다.

관련 주제:

다중 프로젝트 파이프라인 구성 예제.
특정 브랜치, 태그 또는 커밋에 대한 파이프라인을 실행하려면, 트리거 토큰을 사용하여 파이프라인 트리거 API와 인증할 수 있습니다. 트리거 토큰은 trigger 키워드와 다릅니다.

`trigger:include`

trigger:include를 사용하여 작업이 “트리거 작업”임을 선언하고, 자식 파이프라인을 시작합니다.

trigger:include:artifact를 사용하여 동적 자식 파이프라인을 트리거합니다.

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

가능한 입력:

자식 파이프라인의 구성 파일 경로.

trigger:include 예시:

trigger-child-pipeline:
  trigger:
    include: path/to/child-pipeline.gitlab-ci.yml

관련 주제:

자식 파이프라인 구성 예시.

`trigger:project`

trigger:project를 사용하여 작업이 “트리거 작업”임을 선언하고, 다중 프로젝트 파이프라인을 시작합니다.

기본적으로, 다중 프로젝트 파이프라인은 기본 브랜치에 대해 트리거됩니다. trigger:branch를 사용하여 다른 브랜치를 지정하십시오.

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

가능한 입력:

다운스트림 프로젝트의 경로. CI/CD 변수는 지원됩니다 GitLab 15.3 이상에서 사용 가능하며, 작업 전용 변수는 지원되지 않습니다.

trigger:project 예시:

trigger-multi-project-pipeline:
  trigger:
    project: my-group/my-project

다른 브랜치에 대한 trigger:project 예시:

trigger-multi-project-pipeline:
  trigger:
    project: my-group/my-project
    branch: development

관련 주제:

다중 프로젝트 파이프라인 구성 예시.
특정 브랜치, 태그 또는 커밋에 대해 파이프라인을 실행하려면 트리거 토큰을 사용하여 파이프라인 트리거 API와 인증할 수 있습니다. 트리거 토큰은 trigger 키워드와 다릅니다.

`trigger:strategy`

trigger:strategy를 사용하여 trigger 작업이 다운스트림 파이프라인이 완료될 때까지 기다리도록 강제할 수 있습니다 그 후에야 성공으로 표시됩니다.

이 동작은 기본값과 다릅니다. 기본값은 다운스트림 파이프라인이 생성되자마자 trigger 작업을 성공으로 표시합니다.

이 설정은 파이프라인 실행을 병렬이 아닌 선형으로 만듭니다.

trigger:strategy 예시:

trigger_job:
  trigger:
    include: path/to/child-pipeline.yml
    strategy: depend

이 예제에서 후속 단계의 작업은 트리거된 파이프라인이 성공적으로 완료될 때까지 기다립니다.

추가 세부정보:

다운스트림 파이프라인의 선택적 수동 작업은 다운스트림 파이프라인이나 업스트림 트리거 작업의 상태에 영향을 미치지 않습니다. 다운스트림 파이프라인은 선택적 수동 작업을 실행하지 않고도 성공적으로 완료될 수 있습니다.
다운스트림 파이프라인의 차단 수동 작업은 트리거 작업이 성공적이거나 실패로 표시되기 전에 실행되어야 합니다. 다운스트림 파이프라인 상태가 수동 작업으로 인해 수동 작업 대기 중 ()인 경우 트리거 작업은 보류 중 ()으로 표시됩니다. 기본적으로, 나중 단계의 작업은 트리거 작업이 완료될 때까지 시작하지 않습니다.
다운스트림 파이프라인에 실패한 작업이 있을 경우, 그러나 작업이 allow_failure: true를 사용하는 경우, 다운스트림 파이프라인은 성공으로 간주되며 트리거 작업은 성공으로 표시됩니다.

`trigger:forward`

GitLab 15.1에서 일반적으로 사용 가능합니다. 기능 플래그 ci_trigger_forward_variables가 제거되었습니다.

trigger:forward를 사용하여 하위 파이프라인에 전달할 내용을 지정하십시오.

부모-자식 파이프라인(parent-child pipelines)과 다중 프로젝트 파이프라인(multi-project pipelines) 모두에 전달되는 내용을 제어할 수 있습니다.

전달된 변수는 기본적으로 중첩된 하위 파이프라인에서 다시 전달되지 않으며, 중첩된 하위 트리거 작업도 trigger:forward를 사용할 때만 전달됩니다.

가능한 입력값:

yaml_variables: true(기본값) 또는 false. true일 경우, 트리거 작업에서 정의된 변수가 하위 파이프라인에 전달됩니다.
pipeline_variables: true 또는 false(기본값). true일 경우, 파이프라인 변수가 하위 파이프라인에 전달됩니다.

trigger:forward의 예:

이 파이프라인을 수동으로 실행하여 CI/CD 변수 MYVAR = my value를 사용하십시오:

variables: # 각 작업에 대한 기본 변수
  VAR: 값

# 기본 동작:
# - VAR가 자식에게 전달됩니다
# - MYVAR는 자식에게 전달되지 않습니다
child1:
  trigger:
    include: .child-pipeline.yml

# 파이프라인 변수를 전달합니다:
# - VAR가 자식에게 전달됩니다
# - MYVAR가 자식에게 전달됩니다
child2:
  trigger:
    include: .child-pipeline.yml
    forward:
      pipeline_variables: true

# YAML 변수를 전달하지 않습니다:
# - VAR가 자식에게 전달되지 않습니다
# - MYVAR가 자식에게 전달되지 않습니다
child3:
  trigger:
    include: .child-pipeline.yml
    forward:
      yaml_variables: false

추가 세부사항:

trigger:forward를 사용하여 하위 파이프라인에 전달된 CI/CD 변수는 파이프라인 변수로, 우선 순위가 높습니다. 하위 파이프라인에 동일한 이름의 변수가 정의되어 있다면, 일반적으로 해당 변수는 전달된 변수에 의해 덮어씌워집니다.

`variables`

variables를 사용하여 작업에 대한 CI/CD 변수를 정의하십시오.

키워드 유형: 전역 및 작업 키워드. 전역 수준에서 사용할 수 있으며, 작업 수준에서도 사용할 수 있습니다.

variables를 전역 키워드로 정의할 경우, 모든 작업에 대한 기본 변수처럼 동작합니다. 각 변수는 파이프라인 생성 시 모든 작업 구성에 복사됩니다. 이미 해당 변수가 정의된 작업이 있는 경우, 작업 수준 변수 우선 순위가 적용됩니다.

전역 수준에서 정의된 변수는 include와 같은 다른 전역 키워드의 입력으로 사용할 수 없습니다. 이러한 변수는 작업 수준에서만 사용할 수 있으며, script, before_script, 또는 after_script 섹션 및 rules와 같은 일부 작업 키워드에서만 사용 가능합니다.

가능한 입력값: 변수 이름과 값 쌍:

이름은 숫자, 문자 및 밑줄(_)만 사용할 수 있습니다. 일부 셸에서는 첫 번째 문자가 문자가 되어야 합니다.
값은 문자열이어야 합니다.

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

variables의 예:

variables:
  DEPLOY_SITE: "https://example.com/"

deploy_job:
  stage: deploy
  script:
    - deploy-script --url $DEPLOY_SITE --path "/"
  environment: production

deploy_review_job:
  stage: deploy
  variables:
    REVIEW_PATH: "/review"
  script:
    - deploy-review-script --url $DEPLOY_SITE --path $REVIEW_PATH
  environment: production

추가 세부사항:

YAML로 정의된 모든 변수는 연결된 Docker 서비스 컨테이너에도 설정됩니다.
YAML로 정의된 변수는 비민감 프로젝트 구성을 위해 사용됩니다. 민감한 정보는 보호된 변수 또는 CI/CD 비밀로 저장하십시오.
수동 파이프라인 변수 및 일정된 파이프라인 변수는 기본적으로 하위 파이프라인으로 전달되지 않습니다. trigger:forward를 사용하여 이러한 변수를 하위 파이프라인으로 전달하십시오.

관련 주제:

미리 정의된 변수는 러너가 자동으로 생성하여 작업에서 사용할 수 있도록 만든 변수입니다.
변수를 사용하여 러너의 동작을 구성할 수 있습니다.

`variables:description`

description 키워드를 사용하여 파이프라인 수준(전역) 변수에 대한 설명을 정의합니다.

설명은 수동으로 파이프라인을 실행할 때 미리 채워진 변수 이름과 함께 표시됩니다.

키워드 유형: 전역 키워드. 작업 수준 변수에는 사용할 수 없습니다.

가능한 입력:

문자열.

variables:description의 예:

variables:
  DEPLOY_NOTE:
    description: "배포 노트. 이 배포의 이유를 설명합니다."

추가 세부정보:

value 없이 사용되면, 변수가 수동으로 트리거되지 않은 파이프라인에 존재하며, 기본 값은 빈 문자열('')입니다.

`variables:value`

value 키워드를 사용하여 파이프라인 수준(전역) 변수의 값을 정의합니다.

variables: description과 함께 사용되면, 변수 값은 수동으로 파이프라인을 실행할 때 미리 채워집니다.

키워드 유형: 전역 키워드. 작업 수준 변수에는 사용할 수 없습니다.

가능한 입력:

문자열.

variables:value의 예:

variables:
  DEPLOY_ENVIRONMENT:
    value: "staging"
    description: "배포 대상. 필요에 따라 이 변수를 'canary' 또는 'production'으로 변경하세요."

추가 세부정보:

variables: description 없이 사용되면 동작은 variables와 동일합니다.

`variables:options`

도입됨 GitLab 15.7에서.

variables:options를 사용하여 수동으로 파이프라인을 실행할 때 UI에서 선택할 수 있는 값의 배열을 정의합니다.

variables: value와 함께 사용해야 하며, value에 정의된 문자열은 다음과 같습니다:

options 배열의 문자열 중 하나여야 합니다.
기본 선택입니다.

description이 없으면, 이 키워드는 영향을 미치지 않습니다.

키워드 유형: 전역 키워드. 작업 수준 변수에는 사용할 수 없습니다.

가능한 입력:

문자열 배열.

variables:options의 예:

variables:
  DEPLOY_ENVIRONMENT:
    value: "staging"
    options:
      - "production"
      - "staging"
      - "canary"
    description: "배포 대상. 기본적으로 'staging'으로 설정합니다."

`variables:expand`

도입됨 GitLab 15.6에서 플래그와 함께 ci_raw_variables_in_yaml_config. 기본적으로 비활성화되어 있습니다.

GitLab.com에서 활성화됨 GitLab 15.6에.

자체 관리에서 활성화됨 GitLab 15.7에.

일반적으로 사용 가능 GitLab 15.8에. 기능 플래그 ci_raw_variables_in_yaml_config 제거됨.

expand 키워드를 사용하여 변수를 확장 가능 여부를 설정합니다.

키워드 유형: 전역 및 작업 키워드. 전역 수준에서도 사용할 수 있으며, 작업 수준에서도 사용할 수 있습니다.

가능한 입력:

true (기본값): 변수가 확장 가능함.
false: 변수가 확장 불가능함.

variables:expand의 예:

variables:
  VAR1: value1
  VAR2: value2 $VAR1
  VAR3:
    value: value3 $VAR1
    expand: false

VAR2의 결과는 value2 value1입니다.
VAR3의 결과는 value3 $VAR1입니다.

추가 세부정보:

expand 키워드는 전역 및 작업 수준의 variables 키워드와만 함께 사용할 수 있습니다.

rules:variables나 workflow:rules:variables와 함께 사용할 수 없습니다.

`when`

when을 사용하여 작업이 실행될 조건을 구성합니다. 작업에서 정의되지 않은 경우, 기본 값은 when: on_success입니다.

키워드 유형: 작업 키워드. 작업의 일부로 사용할 수 있습니다. when: always와 when: never도 workflow:rules에서 사용할 수 있습니다.

가능한 입력 값:

on_success (기본값): 이전 단계의 작업이 실패하지 않을 때만 작업을 실행합니다.
on_failure: 이전 단계의 작업 중 하나라도 실패할 때만 작업을 실행합니다.
never: 이전 단계의 작업 상태와 관계없이 작업을 실행하지 않습니다. rules 섹션 또는 workflow: rules에서만 사용할 수 있습니다.
always: 이전 단계의 작업 상태와 관계없이 작업을 실행합니다.
manual: 작업을 수동 작업으로 파이프라인에 추가합니다.
delayed: 작업을 지연 작업으로 파이프라인에 추가합니다.

when의 예:

stages:
  - build
  - cleanup_build
  - test
  - deploy
  - cleanup

build_job:
  stage: build
  script:
    - make build

cleanup_build_job:
  stage: cleanup_build
  script:
    - cleanup build when failed
  when: on_failure

test_job:
  stage: test
  script:
    - make test

deploy_job:
  stage: deploy
  script:
    - make deploy
  when: manual
  environment: production

cleanup_job:
  stage: cleanup
  script:
    - cleanup after jobs
  when: always

이 예시에서 스크립트는 다음과 같이 실행됩니다:

build_job이 실패할 때만 cleanup_build_job이 실행됩니다.
성공 여부와 관계없이 파이프라인의 마지막 단계에서 항상 cleanup_job이 실행됩니다.
GitLab UI에서 수동으로 실행할 때 deploy_job이 실행됩니다.

추가 세부사항:

on_success 및 on_failure에 대한 작업 상태 평가 시:
- 이전 단계에서 allow_failure: true인 작업은 실패하더라도 성공으로 간주됩니다.
- 이전 단계에서 생략된 작업(예: 아직 시작되지 않은 수동 작업)은 성공으로 간주됩니다.
allow_failure의 기본값은 manual일 경우 true입니다. 기본값은 rules:when: manual로 변경될 때 false로 변경됩니다.

관련 주제:

when은 더 동적인 작업 제어를 위해 rules와 함께 사용할 수 있습니다.
when은 파이프라인 시작을 제어하기 위해 workflow와 함께 사용할 수 있습니다.

`manual_confirmation`

도입됨 GitLab 17.1에서.

manual_confirmation을 when: manual과 함께 사용하여 수동 작업의 사용자 정의 확인 메시지를 정의합니다. when: manual로 정의된 수동 작업이 없으면 이 키워드는 효과가 없습니다.

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

가능한 입력 값:

확인 메시지를 포함하는 문자열.

manual_confirmation의 예:

delete_job:
  stage: post-deployment
  script:
    - make delete
  when: manual
  manual_confirmation: '정말로 $CI_ENVIRONMENT_SLUG를 삭제하시겠습니까?'

사용 중단된 키워드

다음 키워드는 사용 중단되었습니다.

참고: 이 키워드는 여전히 이전 버전과의 호환성을 보장하기 위해 사용할 수 있으며,

향후 주요 마일스톤에서 제거될 수 있습니다.

전역으로 정의된 `image`, `services`, `cache`, `before_script`, `after_script`

image, services, cache, before_script, 및 after_script를 전역으로 정의하는 것은 사용 중단되었습니다.

상위 수준에서 이 키워드를 사용하는 것은 여전히 이전 버전과의 호환성을 보장하기 위해 가능하지만,

향후 마일스톤에서 제거될 수 있습니다.

대신 default를 사용하세요. 예를 들어:

default:
  image: ruby:3.0
  services:
    - docker:dind
  cache:
    paths: [vendor/]
  before_script:
    - bundle config set path vendor/bundle
    - bundle install
  after_script:
    - rm -rf tmp/

`only` / `except`

참고: only와 except는 사용 중단되었으며 현재 적극적으로 개발되지 않고 있습니다.

이 키워드는 여전히 이전 버전과의 호환성을 보장하기 위해 사용할 수 있지만,

향후 마일스톤에서 제거될 수 있습니다. 파이프라인에 작업을 추가할 때 사용 시점을 제어하려면

대신 rules를 사용하세요.

only와 except를 사용하여 파이프라인에 작업을 추가하는 시점을 제어할 수 있습니다.

only를 사용하여 작업이 실행되는 시점을 정의합니다.
except를 사용하여 작업이 실행되지 않는 시점을 정의합니다.

`only:refs` / `except:refs`

참고: only:refs와 except:refs는 사용 중단되었으며 현재 적극적으로 개발되지 않고 있습니다.

이 키워드는 여전히 이전 버전과의 호환성을 보장하기 위해 사용할 수 있지만,

향후 마일스톤에서 제거될 수 있습니다. refs, 정규 표현식 또는 변수를 사용하여

파이프라인에 작업을 추가할 시점을 제어하려면 대신 rules:if를 사용하세요.

only:refs 및 except:refs 키워드를 사용하여 브랜치 이름이나

파이프라인 유형에 따라 파이프라인에 작업을 추가하는 시점을 제어할 수 있습니다.

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

가능한 입력: 다음을 포함하는 배열:

예를 들어 main 또는 my-feature-branch와 같은 브랜치 이름.
브랜치 이름과 일치하는 정규 표현식, 예를 들어 /^feature-.*/.

다음 키워드:

값	설명
`api`	파이프라인 API에 의해 트리거된 파이프라인.
`branches`	파이프라인의 Git 참조가 브랜치일 때.
`chat`	GitLab ChatOps 명령을 사용하여 생성된 파이프라인.
`external`	GitLab 이외의 CI 서비스를 사용할 때.
`external_pull_requests`	GitHub에서 외부 풀 요청이 생성되거나 업데이트될 때(자세한 내용은 외부 풀 요청을 위한 파이프라인).
`merge_requests`	머지 요청이 생성되거나 업데이트될 때 생성된 파이프라인. 머지 요청 파이프라인, 병합 결과 파이프라인, 머지 기차를 활성화합니다.
`pipelines`	API를 사용하여 생성된 멀티 프로젝트 파이프라인 또는 `trigger` 키워드.
`pushes`	`git push` 이벤트에 의해 트리거된 파이프라인, 브랜치 및 태그 포함.
`schedules`	예약된 파이프라인.
`tags`	파이프라인의 Git 참조가 태그일 때.
`triggers`	트리거 토큰을 사용하여 생성된 파이프라인.
`web`	GitLab UI의 새 파이프라인 선택으로 생성된 파이프라인, 프로젝트의 Build > Pipelines 섹션에서.

only:refs 및 except:refs의 예:

job1:
  script: echo
  only:
    - main
    - /^issue-.*$/
    - merge_requests

job2:
  script: echo
  except:
    - main
    - /^stable-branch.*$/
    - schedules

추가 세부정보:

예약된 파이프라인은 특정 브랜치에서 실행되므로 only: branches로 구성된 작업은 예약된 파이프라인에서도 실행됩니다.

작업에 except: schedules를 추가하여 only: branches가 있는 작업의 실행을 방지하세요.
다른 키워드 없이 사용된 only 또는 except는 only: refs 또는 except: refs와 동등합니다.

예를 들어, 다음 두 작업 구성은 동일한 동작을 합니다:
```
job1:
  script: echo
  only:
    - branches

job2:
  script: echo
  only:
    refs:
      - branches
```
작업이 only, except 또는 rules를 사용하지 않으면, 기본적으로 only는 branches와 tags로 설정됩니다.

예를 들어, job1과 job2는 동일합니다:
```
job1:
  script: echo "test"

job2:
  script: echo "test"
  only:
    - branches
    - tags
```

`only:variables` / `except:variables`

참고: only:variables 및 except:variables는 더 이상 사용되지 않으며 적극적으로 개발되고 있지 않습니다.

이러한 키워드는 이전 버전과의 호환성을 보장하기 위해 여전히 사용 가능하지만 향후 마일스톤에서 제거될 수 있습니다.

파이프라인에 작업을 추가하는 시점을 제어하기 위해 refs, 정규식 또는 변수를 사용하려면 대신 rules:if를 사용하십시오.

only:variables 또는 except:variables 키워드를 사용하여 CI/CD 변수의 상태에 따라 파이프라인에 작업을 추가하는 시점을 제어할 수 있습니다.

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

가능한 입력:

CI/CD 변수 표현식의 배열입니다.

only:variables 예시:

deploy:
  script: cap staging deploy
  only:
    variables:
      - $RELEASE == "staging"
      - $STAGING

`only:changes` / `except:changes`

only:variables 및 except:variables

참고: only:changes 및 except:changes는 더 이상 사용되지 않으며 적극적으로 개발되고 있지 않습니다.

이러한 키워드는 이전 버전과의 호환성을 보장하기 위해 여전히 사용 가능하지만 향후 마일스톤에서 제거될 수 있습니다.

파일 변경을 제어하는 작업을 파이프라인에 추가하려면 rules:changes를 대신 사용하십시오.

changes 키워드를 only와 함께 사용하여 작업을 실행하거나 except와 함께 사용하여 작업을 건너뛸 수 있습니다. 이는 Git 푸시 이벤트가 파일을 수정할 때 적용됩니다.

changes를 사용하여 다음 refs와 함께 사용하는 파이프라인:

branches
external_pull_requests
merge_requests

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

가능한 입력: 다음을 포함하는 배열:

파일 경로.
다음을 위한 와일드카드 경로:
- 단일 디렉터리, 예: path/to/directory/*.
- 디렉터리 및 해당 모든 하위 디렉터리, 예: path/to/directory/**/*.
동일한 확장명 또는 여러 확장명의 모든 파일에 대한 와일드카드 glob 경로, 예: *.md 또는 path/to/directory/*.{rb,py,sh}.
루트 디렉터리의 파일에 대한 와일드카드 경로 또는 모든 디렉터리, 큰따옴표로 감쌈. 예: "*.json" 또는 "**/*.json".

only:changes 예시:

docker build:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  only:
    refs:
      - branches
    changes:
      - Dockerfile
      - docker/scripts/*
      - dockerfiles/**/*
      - more_scripts/*.{rb,py,sh}
      - "**/*.json"

추가 세부정보:

changes는 변경된 파일이 있는 경우 true로 평가됩니다 (OR 연산).
Glob 패턴은 Ruby의 File.fnmatch와 함께 플래그 File::FNM_PATHNAME | File::FNM_DOTMATCH | File::FNM_EXTGLOB으로 해석됩니다.
branches, external_pull_requests 또는 merge_requests 이외의 refs를 사용하는 경우 changes는 특정 파일이 새 파일인지 구 파일인지 판단할 수 없으며 항상 true를 반환합니다.
다른 refs와 함께 only: changes를 사용하는 경우 작업은 변경 사항을 무시하고 항상 실행됩니다.
다른 refs와 함께 except: changes를 사용하는 경우 작업은 변경 사항을 무시하고 절대 실행되지 않습니다.

관련 주제:

only: changes를 사용할 때 작업이나 파이프라인이 예기치 않게 실행될 수 있습니다.

`only:kubernetes` / `except:kubernetes`

참고:

only:kubernetes 및 except:kubernetes는 더 이상 사용되지 않으며, 활성 개발이 이루어지지 않습니다.

이 키워드는 여전히 이전 버전과의 호환성을 보장하기 위해 사용할 수 있지만, 향후 마일스톤에서 제거될 수 있습니다. Kubernetes 서비스가 프로젝트에서 활성화되어 있을 때 작업이 파이프라인에 추가되는지 여부를 제어하려면 rules:if와 CI_KUBERNETES_ACTIVE 미리 정의된 CI/CD 변수를 대신 사용하세요.

Kubernetes 서비스가 프로젝트에서 활성화되어 있을 때 작업이 파이프라인에 추가되는지 제어하려면 only:kubernetes 또는 except:kubernetes를 사용하세요.

키워드 유형: 작업 특정. 작업의 일부로만 사용할 수 있습니다.

가능한 입력:

kubernetes 전략은 오직 active 키워드만 허용합니다.

only:kubernetes의 예:

deploy:
  only:
    kubernetes: active

이 예제에서 deploy 작업은 Kubernetes 서비스가 프로젝트에서 활성화될 때만 실행됩니다.