키워드
전역 키워드
헤더 키워드
- 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-ci.yml 파일의 구성 옵션을 나열합니다. 이 파일은 파이프라인을 구성하는 CI/CD 작업을 정의하는 곳입니다.

이미 기본 CI/CD 개념에 익숙하다면, 간단한 또는 복잡한 파이프라인을 보여주는 튜토리얼을 따라 직접 .gitlab-ci.yml 파일을 만들어 보세요.
예시들은 GitLab CI/CD 예시에서 확인할 수 있습니다.
기업에서 사용되는 큰 .gitlab-ci.yml 파일을 보려면 .gitlab-ci.yml file 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`	Identity 페더레이션을 사용하여 서드파티 서비스를 인증합니다.
`image`	Docker 이미지를 사용합니다.
`inherit`	모든 작업이 상속하는 전역 기본값을 선택합니다.
`interruptible`	새로운 실행에 의해 불필요하게 되었을 때 작업을 취소할 수 있는지 여부를 정의합니다.
`needs`	스테이지 순서보다 빨리 작업을 실행합니다.
`pages`	작업의 결과를 GitLab Pages에서 사용하도록 업로드합니다.
`parallel`	작업의 병렬 실행 횟수입니다.
`release`	러너가 릴리스 오브젝트를 생성하도록 지시합니다.
`resource_group`	작업 동시성을 제한합니다.
`retry`	작업 실패시 자동으로 다시 시도할 수 있는 시간과 횟수입니다.
`rules`	작업의 선택된 속성을 평가하고 결정하는 조건 디렉터리입니다. 생성되었는지 여부를 확인합니다.
`script`	러너가 실행하는 셸 스크립트입니다.
`secrets`	작업이 필요로 하는 CI/CD 비밀입니다.
`services`	Docker 서비스 이미지를 사용합니다.
`stage`	작업 단계를 정의합니다.
`tags`	러너를 선택하는 데 사용되는 태그 디렉터리입니다.
`timeout`	프로젝트 전역 설정보다 우선하는 사용자 정의 작업 시간 제한을 정의합니다.
`trigger`	하류 파이프라인 트리거를 정의합니다.
`variables`	작업 수준에서 작업 변수를 정의합니다.
`when`	작업을 실행하는 조건입니다.

전역 키워드

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

`default`

GitLab 16.4에서 id_tokens를 지원합니다.

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

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

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

after_script
artifacts
before_script
cache
hooks
id_tokens
image
interruptible
retry
services
tags
timeout, 이슈 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: ruby:2.7를 무시하고 작업에서 정의된 image: ruby:2.7을 사용합니다.

추가 세부 정보:

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

`include`

이동함 GitLab 11.4에서 GitLab 무료 버전으로.

CI/CD 구성에서 외부 YAML 파일을 포함하는 데 include를 사용하세요.
하나의 긴 .gitlab-ci.yml 파일을 여러 파일로 분할하여 가독성을 늘리거나, 동일한 구성을 여러 곳에서 중복으로 사용하지 않도록 합니다.

또한 중앙 리포지터리에 템플릿 파일을 저장하고 프로젝트에서 이를 포함할 수 있습니다.

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

.gitlab-ci.yml 파일과 Merge됩니다.
항상 먼저 평가되고, 그 후에 .gitlab-ci.yml 파일의 내용과 Merge됩니다. include 키워드의 위치에 상관없이 항상 이뤄집니다.

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

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

가능한 입력값: include 하위 키워드:

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

그리고 선택적으로:

추가 세부 정보:

일부 CI/CD 변수만 include 키워드와 함께 사용할 수 있습니다.
Merge을 사용하여 로컬에서 포함된 CI/CD 구성을 사용자 정의하고 재정의합니다.
.gitlab-ci.yml 파일에서 동일한 작업 이름이나 전역 키워드를 가지고 포함된 구성을 재정의할 수 있습니다. 두 구성이 Merge되고, 포함된 구성보다 .gitlab-ci.yml 파일의 구성이 우선합니다.
작업을 다시 실행하면 include 파일이 다시 가져오지 않습니다. 파이프라인의 모든 작업은 파이프라인을 만들 때 가져온 구성을 사용합니다. 소스 include 파일에 대한 변경 사항은 작업을 다시 실행하지 않습니다.
파이프라인을 다시 실행하면 include 파일이 다시 가져옵니다. 마지막 파이프라인 실행 후 변경된 경우, 새로운 파이프라인은 변경된 구성을 사용합니다.
기본적으로 파이프라인 당 최대 150개의 포함된 파일이 가능합니다. 추가로:
- GitLab 16.0 이상의 경우, Self-managed 사용자는 최대 포함 값을 변경할 수 있습니다.
- GitLab 15.10 이상의 경우, 최대 150개의 포함된 파일이 가능합니다. 중첩된 포함에서 동일한 파일을 여러 번 포함할 수 있지만, 중복된 포함은 제한에 포함됩니다.
- GitLab 14.9에서 15.9까지의 경우, 최대 100개의 포함된 파일이 가능합니다. 중첩된 포함에서 동일한 파일을 여러 번 포함할 수 있지만, 중복은 무시됩니다.
- GitLab 14.9 이하에서 최대 100개의 포함된 파일이 가능하지만, 동일한 파일을 여러 번 포함할 수는 없습니다.

관련 토픽:

`include:component`

include:component를 사용하여 CI/CD 컴포넌트를 파이프라인 구성에 추가하세요.

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

가능한 입력값: CI/CD 컴포넌트의 전체 주소, <fully-qualified-domain-name>/<project-path>/<component-name>@<specific-version> 형식으로 포맷팅된 것입니다.

include:component의 예시:

include:
  - component: gitlab.example.com/my-org/security-components/secret-detection@1.0

관련 토픽:

CI/CD 컴포넌트 사용하기.

`include:local`

include:local을 사용하여 구성 키워드를 포함하는 파일이 동일한 리포지터리와 브랜치에 있는 파일을 포함하세요.
심볼릭 링크 대신 include:local을 사용하세요.

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

가능한 입력값:

루트 디렉터리( / )에 대한 전체 경로:

YAML 파일은 확장명이 .yml 또는 .yaml이어야 합니다.
파일 경로에 와일드카드 * 및 **를 사용할 수 있습니다. (includes.md#use-includelocal-with-wildcard-file-paths).
일부 CI/CD 변수를 사용할 수 있습니다.

include:local의 예시:

include:
  - local: '/templates/.gitlab-ci-template.yml'

또한 경로를 정의하는 더 짧은 문법을 사용할 수 있습니다:

include: '.gitlab-ci-production.yml'

추가 세부 정보:

.gitlab-ci.yml 파일 및 로컬 파일은 동일한 브랜치에 있어야 합니다.
Git 서브모듈 경로를 통해 로컬 파일을 포함할 수 없습니다.
모든 중첩된 포함은 include 키워드를 포함하는 구성 파일의 프로젝트 범위에서 실행되며, 파이프라인 실행 중인 프로젝트 범위가 아닙니다.

`include:project`

GitLab 13.6에서 동일 GitLab 인스턴스의 다른 비공개 프로젝트에서 여러 파일을 포함하는 기능이 도입되었습니다. GitLab 13.8에서 피처 플래그가 삭제되었습니다.

동일한 GitLab 인스턴스의 다른 비공개 프로젝트에서 파일을 포함하려면 include:project와 include:file을 사용하세요.

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

가능한 입력값:

include:project: 전체 GitLab 프로젝트 경로.
include:file: 루트 디렉터리 (/) 내에서 전체 파일 경로 또는 파일 경로 배열. YAML 파일은 .yml 또는 .yaml 확장명을 가져야 합니다.
include:ref: 선택 사항. 파일을 검색할 ref. 지정되지 않은 경우 기본값은 프로젝트의 HEAD입니다.
일부 CI/CD 변수를 사용할 수 있습니다.

include:project의 예시:

include:
  - project: 'my-group/my-project'
    file: '/templates/.gitlab-ci-template.yml'
  - project: 'my-group/my-subgroup/my-project-2'
    file:
      - '/templates/.builds.yml'
      - '/templates/.tests.yml'

ref를 지정할 수도 있습니다:

include:
  - project: 'my-group/my-project'
    ref: main                                      # Git 브랜치
    file: '/templates/.gitlab-ci-template.yml'
  - project: 'my-group/my-project'
    ref: v1.0.0                                    # Git 태그
    file: '/templates/.gitlab-ci-template.yml'
  - project: 'my-group/my-project'
    ref: 787123b47f14b552955ca2786bc9542ae66fee5b  # Git SHA
    file: '/templates/.gitlab-ci-template.yml'

추가 세부 정보:

모든 방법으로 포함된 .gitlab-ci.yml 파일 구성은 파이프라인이 시작할 때 평가됩니다. 구성은 시간에 따른 스냅샷이며 데이터베이스에 유지됩니다. GitLab은 참조된 .gitlab-ci.yml 파일 구성의 변경 사항을 반영하지 않습니다. 다음 파이프라인이 시작될 때까지.
다른 비공개 프로젝트에서 YAML 파일을 포함하면 파이프라인을 실행하는 사용자가 두 프로젝트의 구성원이어야 하고 파이프라인을 실행할 적절한 권한을 가져야 합니다. 포함된 파일 중 하나에 대한 액세스 권한이 없는 경우 ‘찾을 수 없음 또는 액세스 거부됨’ 오류가 표시될 수 있습니다.
다른 프로젝트의 CI/CD 구성 파일을 포함할 때 주의하십시오. CI/CD 구성 파일이 변경 될 때 파이프라인 또는 알림이 트리거되지 않습니다. 보안적인 측면에서, 이는 제3자 의존성을 가져오는 것과 유사합니다. ref에 대해 다음 사항을 고려하십시오:
- 가장 안정된 옵션이어야 하는 특정한 SHA 해시를 사용하십시오. 사용하려는 커밋이 명확해지도록 SHA 해시의 전체 40자를 사용하십시오. ‘ref’의 짧은 SHA 해시를 사용하는 것은 모호할 수 있습니다.
- 다른 프로젝트의 ref에 보호된 브랜치 및 보호된 태그 규칙을 적용하십시오. 보호된 태그와 브랜치는 변경 전에 변경 관리를 더 자주 거치기 때문에 더 안정적입니다.

`include:remote`

include:remote를 사용하여 다른 위치의 파일을 포함시킵니다.

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

가능한 입력:

HTTP/HTTPS GET 요청에 의해 접근 가능한 공용 URL:

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

include:remote의 예시:

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

추가 세부 정보:

모든 중첩된 포함은 공용 사용자로써 컨텍스트 없이 실행됩니다. 따라서 공용 프로젝트 또는 템플릿만을 포함할 수 있습니다. 중첩된 포함의 include 섹션에는 변수가 없습니다.
다른 프로젝트의 CI/CD 구성 파일을 포함할 때 주의하십시오. 다른 프로젝트의 파일이 변경되면 파이프라인이나 알림이 트리거되지 않습니다. 보안 측면에서 이는 써드파티 의존성을 가져오는 것과 유사합니다. 소유하는 다른 GitLab 프로젝트에 링크하려면 보호된 브랜치 및 보호된 태그의 사용을 고려하여 변경 관리 규칙을 강제할 수 있습니다.

`include:template`

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에서 베타 기능으로 도입되었습니다.

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를 사용할 때 입력 값을 설정하려면 입력 값을 설정합니다.

`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 키워드를 사용합니다.

`워크플로우`

GitLab 12.5에서 도입됨

워크플로우를 사용하여 파이프라인 동작을 제어합니다.

워크플로우 구성에서 사전 정의된 CI/CD 변수를 사용할 수 있지만, 작업이 시작될 때만 정의되는 변수는 사용할 수 없습니다.

관련 주제:

워크플로우: 규칙 예제
브랜치 파이프라인 및 Merge Request 파이프라인 간 전환하기(workflow.md#switch-between-branch-pipelines-and-merge-request-pipelines)

`워크플로우:auto_cancel:on_new_commit`

GitLab 16.8에서 플래그 ci_workflow_auto_cancel_on_new_commit와 함께 도입. 기본적으로 비활성화됨.
GitLab 16.9에서 GitLab.com 및 Self-managed에서 활성화.
GitLab 16.10에서 일반 사용 가능. 피처 플래그 ci_workflow_auto_cancel_on_new_commit 제거됨.

워크플로우:auto_cancel:on_new_commit을 사용하여 자동으로 중복된 파이프라인 취소 기능을 구성합니다.

가능한 입력:

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

워크플로우:auto_cancel:on_new_commit의 예시:

workflow:
  auto_cancel:
    on_new_commit: interruptible

job1:
  interruptible: true
  script: sleep 60

job2:
  interruptible: false  # 정의되지 않은 경우 기본값
  script: sleep 60

이 예시에서:

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

`워크플로우:auto_cancel:on_job_failure`

GitLab 16.10에서 도입되었으며 플래그 auto_cancel_pipeline_on_job_failure와 함께 제공됩니다. 기본적으로 비활성화됨.

플래그: Self-managed GitLab의 경우, 이 기능은 기본적으로 사용할 수 없습니다. 이 기능을 활성화하려면 관리자가 auto_cancel_pipeline_on_job_failure이라는 피처 플래그를 활성화할 수 있습니다. GitLab.com 및 GitLab Dedicated에서는 이 기능을 사용할 수 없습니다.

워크플로우:auto_cancel:on_job_failure를 사용하여 작업 실패 시 즉시 취소해야 할 작업을 구성합니다.

가능한 입력:

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

워크플로우: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이 실행 중이라면 job1이 취소되고 job3은 시작되지 않습니다.

관련 주제:

하위 파이프라인에서 상위 파이프라인 자동 취소하기

`워크플로우:name`

GitLab 15.5에서 플래그 pipeline_name과 함께 도입. 기본적으로 비활성화됨.
GitLab 15.7에서 GitLab.com과 Self-managed에서 활성화.
GitLab 15.8에서 일반 사용 가능. 피처 플래그 pipeline_name이 제거됨.

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

모든 파이프라인에 정의된 이름이 할당됩니다. 이름에서의 선행 또는 후행 공백은 제거됩니다.

가능한 입력:

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

워크플로우: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: 'Ruby 3 파이프라인'
    - when: always  # 다른 파이프라인은 실행할 수 있지만 기본 이름을 사용합니다.

추가 세부 정보:

이름이 빈 문자열인 경우 파이프라인에 이름이 할당되지 않습니다. 모든 변수도 빈 문자열일 경우 이름도 빈 문자열로 평가될 수 있습니다.
workflow:rules:variables는 trigger 작업을 포함하여 모든 작업에서 사용 가능한 글로벌 변수으로 지정되며, 기본적으로 하위 파이프라인으로 변수를 전달합니다. 하위 파이프라인이 동일한 변수를 사용하는 경우, 상위 변수 값에 의해 변수가 덮어씌워집니다. 프로젝트의 파이프라인 구성에서 모든 고유 변수 이름을 사용하거나, inherit:variables를 트리거 작업에서 사용하고 전달할 변수를 명시적으로 나열하세요.

`workflow:rules`

workflow의 rules 키워드는 jobs에서 정의된 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로 끝나지 않고 파이프라인이 어느 경우에도 실행됩니다:

Merge Request
기본 브랜치

추가 세부 정보:

규칙이 모든 브랜치 파이프라인(기본 브랜치 제외)과 Merge Request 파이프라인 둘 다 일치하는 경우, 중복 파이프라인 발생할 수 있습니다.

관련 주제:

workflow:rules 템플릿을 사용하여 미리 구성된 workflow: rules 항목을 가져올 수 있습니다.
workflow:rules에 대한 일반적인 if 절 사용.
Merge Request 파이프라인 실행을 위해 rules 사용.

`workflow:rules:variables`

GitLab 13.11에서 소개.
GitLab 14.1에서 피처 플래그 제거.

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

조건이 일치하는 경우, 변수가 생성되어 파이프라인의 모든 작업에서 사용할 수 있습니다. 변수가 전역 수준에서 이미 정의된 경우, workflow 변수가 우선하고 전역 변수를 재정의합니다.

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

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

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

workflow:rules:variables의 예:

variables:
  DEPLOY_VARIABLE: "default-deploy"

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

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

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

기본 브랜치인 경우:

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

feature인 경우:

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

다른 경우:

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

추가 세부 정보:

workflow:rules:variables은 전역 변수가 되어 모든 작업에 사용됩니다. 디폴트로 변수를 하위 파이프라인으로 전달하는 trigger 작업도 포함됩니다. 하위 파이프라인이 동일한 변수를 사용하는 경우 변수가 덮어씌워집니다. 모든 프로젝트의 파이프라인 구성에서 고유한 변수 이름을 사용하거나:
- trigger 작업에서 inherit:variables를 사용하고 하위 파이프라인으로 전달하려는 정확한 변수를 나열하세요.

`workflow:rules:auto_cancel`

GitLab 16.8에서 소개되었습니다.
기본적으로 비활성화된 ci_workflow_auto_cancel_on_new_commit라는 플래그가 함께 제공됩니다.
GitLab 16.9에서 GitLab.com 및 Self-managed에서 활성화됨.
GitLab 16.10에서 일반적으로 사용 가능합니다. 플래그 ci_workflow_auto_cancel_on_new_commit이 제거되었습니다.

workflow:rules:auto_cancel을 사용하여 workflow:auto_cancel:on_new_commit 기능의 동작을 구성합니다.

가능한 입력:

on_new_commit: workflow:auto_cancel:on_new_commit

workflow:rules:auto_cancel의 예:

workflow:
  auto_cancel:
    on_new_commit: interruptible
  rules:
    - if: $CI_COMMIT_REF_PROTECTED == 'true'
      auto_cancel:
        on_new_commit: none
    - when: always                  # 다른 경우에는 파이프라인 실행

test-job1:
  script: sleep 10
  interruptible: false

test-job2:
  script: sleep 10
  interruptible: true

이 예에서 workflow:auto_cancel:on_new_commit 기본적으로 모든 작업에서 interruptible로 설정되어 있습니다. 그러나 보호된 브랜치에 대해 파이프라인이 실행되면, 해당 규칙은 on_new_commit: none으로 기본 설정을 무시합니다. 예를 들어, 파이프라인이 실행되는 경우:

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

헤더 키워드

일부 키워드는 YAML 구성 파일의 헤더 섹션에 정의되어야합니다. 헤더는 파일의 맨 위에 있어야하며, 다른 구성부분과 ---로 구분되어야합니다.

`spec`

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

파이프라인의 동작을 구성하기 위해 include 키워드로 파이프라인에 구성이 추가될 때 spec 섹션을 헤더에 추가하세요.

`spec:inputs`

spec:inputs를 사용하여 include를 통해 파이프라인에 추가할 CI/CD 구성의 입력 매개변수를 정의할 수 있습니다. include:inputs를 사용하여 파이프라인 실행 시 사용할 값을 정의하세요.

입력을 사용하여 CI/CD 구성이 포함될 때 구성의 동작을 사용자 정의할 수 있습니다.

헤더 섹션 외부의 값을 참조하기 위해 보간 형식 $[[ input.input-id ]]를 사용하세요. 입력은 파이프라인이 생성될 때 구성을 가져오고 Merge되기 전에 계산 및 보간됩니다.

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

가능한 입력: 예상 입력을 나타내는 문자열 해시입니다.

spec:inputs의 예시:

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

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

추가 세부 정보:

입력은 spec:inputs:default를 사용하여 기본값을 설정하지 않는 한 필수입니다.
입력은 더미(default) 값을 설정하지 않는 한 문자열을 기대합니다.
보간 블록 내의 문자열은 1MB를 초과할 수 없습니다.
보간 블록 내의 문자열은 1KB를 초과할 수 없습니다.

관련 주제:

spec:inputs를 사용하여 입력 매개변수 정의.

`spec:inputs:default`

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

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

default: ''를 사용하여 기본값이 없도록 설정하세요.

키워드 유형: 헤더 키워드. specs은 구성 파일의 맨 위에서 헤더 섹션에 선언되어야합니다.

가능한 입력: 기본값을 나타내는 문자열 또는 ''.

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

spec:inputs:description을 사용하여 특정 입력에 설명을 제공하세요. 설명은 입력의 동작에 영향을주지 않으며 파일 사용자가 입력을 이해하는 데 도움이되도록만 사용됩니다.

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

가능한 입력: 설명을 나타내는 문자열.

spec:inputs:description의 예시:

spec:
  inputs:
    flags:
      description: '`flags` 입력 세부 정보에 대한 샘플 설명입니다.'
---

# 파이프라인 구성이 따릅니다...

`spec:inputs:options`

GitLab 16.6에서 소개되었습니다.

입력은 options를 사용하여 입력에 대한 허용된 값 디렉터리을 지정할 수 있습니다. 입력당 옵션은 50개로 제한됩니다.

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

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

spec:inputs:options의 예시:

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

# 파이프라인 구성이 따릅니다...

이 예에서:

environment는 필수이며 디렉터리에 있는 값 중 하나로 정의되어야합니다.

추가 세부 정보:

파이프라인은 다음과 같은 유효성 오류로 실패합니다:
- 입력이 options와 default를 모두 사용하면, 기본값이 디렉터리에 나열된 옵션 중 하나가 아닌 경우.
- 입력 옵션이 type과 일치하지 않는 경우. 이는 options를 사용할 때 boolean이 아닌 string 또는 number여야합니다.

`spec:inputs:regex`

GitLab 16.5에서 소개되었습니다.

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

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

가능한 입력: / 문자로 시작하고 끝나는 정규 표현식이어야합니다.

spec:inputs:regex의 예시:

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

# 파이프라인 구성이 따릅니다...

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

추가 세부 정보:

inputs:regex는 string 유형의 type과 함께 사용될 수 있으며, number 또는 boolean과는 사용될 수 없습니다.

`spec:inputs:type`

기본적으로 입력 항목은 문자열을 기대합니다. spec:inputs:type을 사용하여 입력 항목에 대해 다른 유형을 설정할 수 있습니다.

키워드 유형: 헤더 키워드입니다. specs는 구성 파일의 맨 위에 헤더 섹션으로 선언되어야 합니다.

가능한 입력: 다음 중 하나일 수 있습니다:

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

spec:inputs:type 예시:

spec:
  inputs:
    job_name:
    website:
      type: string
    port:
      type: number
    available:
      type: boolean

작업 키워드

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

`after_script`

after_script을 사용하여 작업의 script 섹션 뒤에 실행되는 명령어 배열을 정의합니다. 여기에는 script_failure 실패 유형을 가진 실패한 작업도 포함됩니다. after_script 명령어는 기타 실패 유형 이후에 실행되지 않습니다.

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

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

한 줄 명령어.
여러 줄에 걸친 긴 명령어 분할.
YAML 앵커.

CI/CD 변수 지원됨.

after_script 예시:

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

추가 상세정보:

after_script에서 지정한 스크립트는 before_script 또는 script 명령어에서 수행한 변경 사항과 별개의 새 셸에서 실행됩니다. 따라서 다음과 같은 동작을 합니다:

현재 작업 디렉터리는 기본값으로 설정됩니다(러너가 Git 요청을 처리하는 방법을 정의하는 변수에 따름).
script 스크립트에서 내보낸 명령 별칭과 변수, before_script 또는 script에서 설치한 소프트웨어 등 작업 디렉터리 밖의 변경 사항(러너 실행기에 따라 다름)에 대한 변경 사항에 접근할 수 없습니다.
별도의 타임아웃이 있습니다. GitLab Runner 16.4와 이후에는 기본값으로 5분이며, RUNNER_AFTER_SCRIPT_TIMEOUT 변수로 구성할 수 있습니다. GitLab 16.3 및 이전에는 타임아웃이 하드코딩되어 5분으로 설정됩니다.
작업의 종료 코드에 영향을 주지 않습니다. script 섹션이 성공하고 after_script이 시간 초과되거나 실패하더라도 작업은 코드 0(작업 성공)으로 종료합니다.

작업이 시간 초과되거나 취소되면 after_script 명령이 실행되지 않습니다. 시간 초과된 또는 취소된 작업에 대한 after_script 명령의 실행을 추가하는 이슈가 있습니다.

관련 주제:

after_script을 default과 함께 사용하여 모든 작업 이후에 실행되어야 하는 명령의 기본 배열을 정의합니다.
0이 아닌 종료 코드 무시.
색 코드를 after_script과 사용하여 작업 로그를 쉽게 확인할 수 있습니다.
사용자 정의 축소 가능한 섹션 만들기로 작업 로그 출력을 간소화할 수 있습니다.

`allow_failure`

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

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

작업이 실패해도 (allow_failure: true) 파이프라인이 성공적이며 해당 커밋이 경고 없이 통과되었음을 나타내는 주황색 경고 ()가 표시됩니다.

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

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

매뉴얼 작업의 경우 true.
when: manual를 사용하는 작업의 경우 rules 내에서 사용하는 경우 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`

GitLab 13.8에서 도입.
GitLab 13.9에서 제거된 피처 플래그.

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 섹션의 일부로만 사용할 수 있습니다. 가능한 입력 값:

프로젝트 디렉터리를 기준으로 한 파일 경로 배열
글로브 패턴 및 다음을 사용할 수 있습니다.
- GitLab Runner 13.0 및 이후, doublestar.Glob.

CI/CD 변수는 지원됨. artifacts:paths의 예:

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

이 예제는 .config 및 binaries 디렉터리의 모든 파일을 포함하는 결과물을 생성합니다.

추가 정보:

artifacts:name과 사용되지 않으면, 결과물 파일은 artifacts로 이름이 지정되며, 다운로드시 artifacts.zip로 변환됩니다.

관련 주제:

특정 작업이 가져올 결과물을 제한하려면 dependencies를 참조하세요.
작업 결과물 생성.

`artifacts:exclude`

GitLab 13.1에 도입
GitLab Runner 13.1가 필요합니다.

artifacts:exclude를 사용하여 결과물 아카이브에 파일이 추가되지 않도록합니다. 키워드 유형: 작업 키워드. 작업 또는 default 섹션의 일부로만 사용할 수 있습니다. 가능한 입력 값:

프로젝트 디렉터리를 기준으로 한 파일 경로 배열
글로브 또는 doublestar.PathMatch 패턴 artifacts:exclude의 예:

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

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

추가 정보:

artifacts:exclude 경로는 재귀적으로 검색되지 않습니다.
artifacts:untracked로 매치된 파일도 artifacts:exclude로 제외될 수 있습니다.

관련 주제:

작업 결과물에서 파일 제외.

`artifacts:expire_in`

피처 플래그가 비활성화된 채로 GitLab 13.0에 도입됨.
GitLab 13.4에서 기본 동작으로 설정됨.
GitLab 13.8에 도입, 최신 작업 결과물을 프로젝트 수준에서 비활성화할 수 있음.
GitLab 13.9에 도입, 최신 작업 결과물을 인스턴스 전반적으로 비활성화할 수 있음.

expire_in을 사용하여 작업 결과물이 만료되어 삭제되기 전에 저장되는 기간을 지정합니다. expire_in 설정은 다음에 영향을 미치지 않습니다:

최신 작업 결과물은 만료 시간과 상관없이 지속적으로 유지됩니다. 최신 작업 결과물의 유지를 비활성화하지 않는 한 프로젝트 수준. 또는 인스턴스 전반적으로. 유지되는 경우. 만료된 후에는 결과물이 기본적으로 시간별로 삭제(크론 작업을 사용)되며 더 이상 액세스할 수 없게 됩니다.

키워드 유형: 작업 키워드입니다. 작업 또는 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에 업로드되고 저장된 시점에서 시작됩니다. 만료 시간이 정의되지 않으면 인스턴스 전반적인 설정으로 기본 설정됩니다.
만료 날짜를 재정의하고 결과물이 자동으로 삭제되는 것을 방지하려면:
- 작업 페이지에서 유지를 선택합니다.
- GitLab 13.3 및 이후, expire_in의 값을 never로 설정합니다.
만료 시간이 너무 짧으면 긴 파이프라인의 나중 단계의 작업이 이전 작업에서 만료된 결과물을 가져오려고 시도할 수 있습니다. 결과물이 만료되면 가져오려고 하는 작업이 needed artifacts를 검색하지 못했습니다오류](../jobs/job_artifacts_troubleshooting.md#error-message-this-job-could-not-start-because-it-could-not-retrieve-the-needed-artifacts) 와 함께 실패합니다. 만료 시간을 더 길게 설정하거나 나중 작업에서 [dependencies`를 사용하여 만료된 결과물을 가져오지 않도록 합니다.

`artifacts:expose_as`

GitLab 12.5에서 소개되었습니다.

artifacts:expose_as 키워드를 사용하여 Merge Request UI에서 작업 아티팩트를 노출할 수 있습니다.

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

가능한 입력값:

Merge Request UI에 표시할 아티팩트 다운로드 링크의 이름. artifacts:paths와 결합해야 합니다.

artifacts:expose_as의 예시:

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

추가 정보:

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

관련 주제:

Merge Request UI에 작업 아티팩트 노출.

`artifacts:name`

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

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

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

가능한 입력값:

아티팩트 아카이브의 이름. CI/CD variables은 지원됩니다. artifacts:paths와 결합해야 합니다.

artifacts:name의 예시:

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

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

관련 주제:

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

`artifacts:public`

GitLab 13.8에서 non_public_artifacts이름의 플래그로 소개되었으며 기본으로 비활성화되었습니다.
GitLab 15.10에서 업데이트되었습니다. 15.10 이전에 artifacts:public으로 생성된 아티팩트는 이 업데이트 이후에 비공개로 유지되지 않을 수 있습니다.
GitLab 16.7에서 일반적으로 사용 가능해졌으며 non_public_artifacts 플래그가 제거되었습니다.

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

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

공개 파이프라인의 아티팩트에 대해 익명, 게스트, 그리고 리포터 사용자에게 읽기 액세스를 거부하려면 artifacts:public을 false로 설정하세요:

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

가능한 입력값:

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

artifacts:public의 예시:

job:
  artifacts:
    public: false

`artifacts:reports`

포함된 템플릿에 의해 생성된 아티팩트를 수집하기 위해 artifacts:reports를 사용하세요.

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

가능한 입력값:

사용 가능한 아티팩트 보고서 유형 디렉터리을 참조하세요.

artifacts:reports의 예시:

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

추가 정보:

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

`artifacts:untracked`

artifacts:untracked를 사용하여 (정의된 artifacts:paths와 함께) 모든 Git 추적되지 않은 파일을 아티팩트로 추가할 수 있습니다. artifacts:untracked은 리포지터리의 .gitignore 구성을 무시하므로 .gitignore에서 매칭되는 아티팩트가 포함됩니다.

키워드 유형: Job 키워드. 작업의 일부로만 사용하거나 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 섹션에서만 사용할 수 있습니다.

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

한 줄 명령어
여러 줄에 걸친 긴 명령어
스크립트용 YAML 앵커

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

before_script의 예시:

job:
  before_script:
    - echo "작업 'script:' 명령어보다 먼저 이 명령을 실행합니다."
  script:
    - echo "이 명령은 작업의 'before_script' 명령어 이후에 실행됩니다."

추가 세부 정보:

before_script에 지정한 스크립트는 주요 script에 지정한 스크립트와 연결됩니다. 결합된 스크립트는 단일 셸에서 함께 실행됩니다.
최상위 수준에서 before_script을 사용하지만 default 섹션에는 사용하지 않는 것이 사라지게되었습니다.

관련 주제:

Use default로 before_script 사용하여 모든 작업의 script 명령어 이전에 실행되어야 하는 기본 배열을 정의할 수 있습니다.
0이 아닌 종료 코드 무시를 할 수 있습니다.
before_script에서 색상 코드 사용하여 작업 로그를 검토하기 쉽게 만들 수 있습니다.
사용자 정의 접이식 섹션을 만들어 작업 로그 출력을 간소화할 수 있습니다.

`cache`

GitLab 15.0에서 도입된 캐시는 보호된 브랜치와 보호되지 않은 브랜치 사이에서 공유되지 않습니다.

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

캐시는 다음과 같습니다:

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

특정 작업에 대해 캐싱을 비활성화하여, 예를 들어:

default로 정의된 기본 캐시
include로 추가된 작업의 구성을 무시할 수 있습니다.

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

`cache:paths`

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

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

가능한 입력값:

프로젝트 디렉터리($CI_PROJECT_DIR)를 기준으로 하는 경로 배열입니다. Glob 패턴을 사용하는 와일드카드를 사용할 수 있습니다:
- 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 사용 사례를 참조하십시오.

`cache:key`

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

지정하지 않으면 기본 키는 default입니다. cache 키워드가 있지만 cache:key가 없는 모든 작업은 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`

GitLab 12.5에 도입되었습니다.

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

키워드 유형: Job 키워드. Job 내에서만 사용하거나 default 섹션에서만 사용할 수 있습니다.

가능한 입력값:

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

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

cache:key:files의 예시:

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

본 예시는 Ruby 및 Node.js 의존성을 위한 캐시를 생성합니다. 이러한 캐시는 현재 버전의 Gemfile.lock 및 package.json 파일에 연결됩니다. 이 파일들 중 하나가 변경되면, 새로운 캐시 키가 계산되고 새로운 캐시가 생성됩니다. cache:key:files를 사용하는 이후의 작업 실행은 Gemfile.lock 및 package.json과 같은 파일에 대해 새로운 캐시를 사용하여 의존성을 다시 만드는 대신 새 캐시를 사용합니다.

추가 세부 정보:

캐시 key는 각 나열된 파일이 변경된 최근 커밋에서 계산된 SHA입니다. 만약 어떤 파일도 커밋에서 변경되지 않았을 경우, 대체 키는 default입니다.

`cache:key:prefix`

GitLab 12.5에 도입되었습니다.

cache:key:prefix를 사용하여 cache:key:files의 SHA에 접두어를 결합합니다.

키워드 유형: Job 키워드. Job 내에서만 사용하거나 default 섹션에서만 사용할 수 있습니다.

가능한 입력값:

문자열
사전 정의된 변수
두 가지를 결합한 것

cache:key:prefix의 예시:

rspec:
  script:
    - echo "이 rspec job은 캐시를 사용합니다."
  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로 체크아웃에 추가되지 않은 파일

추적되지 않는 파일을 캐시로 처리하면:

보통 추적되지 않는 의존성, 예를 들어 젬 또는 노드 모듈
다른 Job에서의 아티팩트. 아티팩트에서 추출된 파일은 기본적으로 추적되지 않습니다.

키워드 유형: Job 키워드. Job 내에서만 사용하거나 default 섹션에서만 사용할 수 있습니다.

가능한 입력값:

true 또는 false (기본값)

cache:untracked의 예시:

rspec:
  script: test
  cache:
    untracked: true

추가 세부 정보:

cache:untracked를 cache:paths와 결합하여 Git 리포지터리의 추적되지 않는 모든 파일과 구성된 경로에 있는 모든 파일을 캐시할 수 있습니다. cache:paths를 사용하여 추적되는 파일이거나 작업 디렉터리 외부에 있는 파일을 포함한 특정 파일을 캐시하고, cache: untracked를 사용하여 추적되지 않는 모든 파일을 캐시할 수 있습니다. 예를 들어:
```
rspec:
  script: test
  cache:
    untracked: true
    paths:
      - binaries/
```
이 예시에서 해당 Job은 리포지터리의 모든 추적되지 않는 파일과 binaries/의 모든 파일을 캐시합니다. binaries/에 추적되지 않는 파일이 있을 경우, 이 두 가지 키워드에 모두 포함됩니다.

`cache:unprotect`

GitLab 15.8에 도입되었습니다.

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

true로 설정하면, 보호된 브랜치에 액세스할 수 없는 사용자도 보호된 브랜치에서 사용하는 캐시 키를 읽을 수도 쓸 수도 있습니다.

키워드 유형: Job 키워드. Job 내에서만 사용하거나 default 섹션에서만 사용할 수 있습니다.

가능한 입력값:

true 또는 false (기본값)

cache:unprotect의 예시:

rspec:
  script: test
  cache:
    unprotect: true

`cache:when`

GitLab 13.5 및 GitLab Runner v13.5.0에서 도입되었습니다.

작업의 상태에 기반하여 언제 캐시를 저장할지 정의하기 위해 cache:when을 사용합니다.

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

키워드 유형: Job 키워드. Job 내에서만 사용하거나 default 섹션에서만 사용할 수 있습니다.

가능한 입력값:

on_success (기본값): Job이 성공했을 때만 캐시 저장
on_failure: Job이 실패했을 때만 캐시 저장
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와 함께 사용하거나 아무 것도 캐시되지 않습니다.

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

가능한 입력값:

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

cache:policy 예시:

prepare-dependencies-job:
  stage: build
  cache:
    key: gems
    paths:
      - vendor/bundle
    policy: push
  script:
    - echo "This job only downloads dependencies and builds the cache."
    - echo "Downloading dependencies..."

faster-test-job:
  stage: test
  cache:
    key: gems
    paths:
      - vendor/bundle
    policy: pull
  script:
    - echo "This job script uses the cache, but does not update it."
    - echo "Running tests..."

`cache:fallback_keys`

cache:fallback_keys를 사용하여 cache:key에 캐시가 없는 경우 캐시를 복원하기 위해 시도할 키 디렉터리을 지정하세요. 캐시는 fallback_keys 섹션에 지정된 순서대로 검색됩니다.

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

가능한 입력값:

캐시 키 배열

cache:fallback_keys 예시:

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

`coverage`

coverage를 사용하여 작업 출력에서 코드 커버리지를 추출하는 방법을 구성할 때 사용합니다. 작업 출력 중 적어도 한 줄이 정규 표현식과 일치하는 경우 UI에 코드 커버리지가 표시됩니다.

가능한 입력값:

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

coverage 예시:

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

:::EndTabs ### dast_configuration

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

History

Introduced in GitLab 14.1.

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

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

가능한 입력값: 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"

`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를 사용하여 작업이 환경을 배포하는 것을 정의합니다.

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

가능한 입력값: 작업이 배포하는 환경의 이름으로, 다음 형식 중 하나여야 합니다:

-, _, /, $, {, } 및 이러한 문자를 포함한 문자 및 숫자 간격 등으로 작성된 일반 텍스트
사전 정의된, 프로젝트, 그룹, 인스턴스 또는 .gitlab-ci.yml 파일에 정의된 변수인 CI/CD 변수. script 섹션에 정의된 변수는 사용할 수 없습니다.

environment의 예시:

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

추가 정보:

환경을 지정하고 해당 이름의 환경이 없는 경우 환경이 생성됩니다.

`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

추가 정보:

작업이 완료된 후 Merge Request, 환경 또는 배포 페이지에서 버튼을 선택하여 URL에 액세스할 수 있습니다.

`environment:on_stop`

on_stop 키워드를 environment 아래에 정의하여 환경을 종료하는 다른 작업을 선언할 수 있습니다.

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

추가 정보: - 자세한 내용 및 예제는 environment:action을 참조하세요.

`environment:action`

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

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

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시간
7일
일주일
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`

GitLab 12.6에서 도입.

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

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

environment:kubernetes의 예시:

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

이 구성은 deploy 작업을 production 환경으로 배포하기 위해 설정합니다. 이때 production Kubernetes 네임스페이스를 사용합니다.

추가 정보:

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

관련 주제:

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

`environment:deployment_tier`

GitLab 13.10에서 도입.

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

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

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

production
staging
testing
development
other

environment:deployment_tier의 예시:

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

추가 정보:

이 작업 정의에서 생성된 환경은 이 값을 기반으로 티어가 할당됩니다.
나중에 이 값을 추가해도 기존 환경의 티어가 업데이트되지 않습니다. 기존 환경은 환경 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로 접근할 수 있습니다.

일반적인 사용 사례는 브랜치용 동적 환경을 생성하고 Review App으로 사용하는 것입니다. Review Apps를 사용한 예시는 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은 파이프라인 생성 시 다음을 수행합니다:

키에 기반하여 역방향으로 깊은 Merge을 수행합니다.
.tests 내용을 rspec 작업과 Merge합니다.
키의 값은 Merge되지 않습니다.

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

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

추가 정보:

GitLab 12.0 이상에서 extends의 부모를 여러 개 사용할 수 있습니다.
extends 키워드는 최대 열한 단계의 상속을 지원하지만 세 단계 이상 사용하는 것을 피해야 합니다.
위의 예시에서 .tests는 숨김 작업입니다. 일반 작업에서도 구성을 확장할 수 있지만 숨김 작업에서도 가능합니다.

관련 주제:

extends를 사용하여 구성 섹션을 재사용하는 것을 참조하려면 구성 파일 포함을 참조하세요.

`hooks`

GitLab 15.6에서 도입되었습니다. ci_hooks_pre_get_sources_script라는 플래그와 함께 버전됩니다. 기본적으로 비활성화됩니다.
GitLab 15.10에서 일반적으로 사용 가능해집니다. 피처 플래그 ci_hooks_pre_get_sources_script가 제거되었습니다.

hooks를 사용하여 작업 실행의 특정 단계에서 러너에서 실행할 명령어 디렉터리을 지정합니다. Git 리포지터리를 검색하기 전과 같은 작업 실행에 대한 특정 단계에서 실행할 명령을 지정하기 위해 사용됩니다.

키워드 유형: 작업 키워드. 작업의 일부로만 또는 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 리포지터리 및 하위 모듈을 복제하기 전에 러너에서 실행할 명령어 디렉터리을 지정합니다. 예를 들어 다음과 같은 목적으로 사용할 수 있습니다:

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

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

한 줄 명령어.
[여러 줄에 걸친] 명령어.
YAML 앵커.

CI/CD 변수는 [지원됩니다]../variables/where_variables_can_be_used.md#gitlab-ciyml-file).

hooks:pre_get_sources_script 예시:

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

관련 주제:

GitLab 러너 구성

`identity`

Tier: Free, Premium, Ultimate Offering: GitLab.com Status: Beta

GitLab 16.9에서 도입되었습니다. google_cloud_support_feature_flag라는 플래그와 함께 베타 기능으로 제공됩니다.

플래그: GitLab.com에서이 기능은 일부 사용자를위한 사용 가능합니다. GitLab Dedicated에서이 기능은 사용할 수 없습니다.

이 기능은 베타 기능입니다. 이 기능을 테스트하는 사용자 디렉터리에 참가하려면 [대기 디렉터리]를 참조하십시오(https://forms.gle/XdxdTxC7DXj4NSaz9).

identity를 사용하여 ID 연합을 사용하여 타사 서비스와 인증을합니다.

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

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

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

identity 예시:

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

관련 주제:

`id_tokens`

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

id_tokens를 사용하여 타사 서비스와의 인증에 JSON 웹 토큰(JWT)을 생성합니다. 이 방식으로 생성된 모든 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

관련 주제:

Sigstore와 함께 키리스 서명.

`image`

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

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

가능한 입력: 필요한 경우 레지스트리 경로를 포함한 이미지의 이름으로 다음 형식 중 하나를 사용합니다:

<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 키워드. Job의 일부로만 또는 default 섹션에서만 사용할 수 있습니다.

가능한 입력값: 다음 중 하나로 이미지의 이름과 레지스트리 경로(필요한 경우)를 포함합니다.

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

관련 주제:

도커 컨테이너에서 CI/CD 작업 실행.

`image:entrypoint`

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

Docker 컨테이너가 생성될 때, entrypoint는 Docker --entrypoint 옵션으로 변환됩니다. 구문은 Dockerfile ENTRYPOINT 지시문과 유사하며, 각각의 셸 토큰은 배열에서 별개의 문자열입니다.

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

가능한 입력값:

문자열.

image:entrypoint 예시:

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

관련 주제:

이미지의 진입점 재정의.

`image:docker`

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

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

키워드 유형: Job 키워드. Job의 일부로만 또는 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 15.2에서 GitLab.com 및 Self-managed에서 활성화되었습니다.
GitLab 15.4에서 일반 사용 가능하여 피처 플래그 ci_docker_image_pull_policy가 제거되었습니다.
GitLab Runner 15.1 이상이 필요합니다.

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

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

가능한 입력값:

단일 가져오기 정책 또는 배열에서 여러 가져오기 정책입니다. always, if-not-present, 또는 never일 수 있습니다.

image:pull_policy 예시:

job1:
  script: echo "단일 가져오기 정책."
  image:
    name: ruby:3.0
    pull_policy: if-not-present

job2:
  script: echo "여러 가져오기 정책."
  image:
    name: ruby:3.0
    pull_policy: [always, if-not-present]

추가 세부 정보:

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

관련 주제:

`inherit`

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

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

`inherit:default`

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

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

가능한 입력값:

모든 기본 키원드의 상속을 활성화 또는 비활성화하기 위해 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를 사용하여 global variables 키워드의 상속을 제어합니다.

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

가능한 입력 값:

true (기본값) 또는 false를 사용하여 모든 전역 변수의 상속을 활성화 또는 비활성화합니다.
상속할 특정 변수의 디렉터리.

inherit:variables의 예시:

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

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

job2:
  script: echo "이 작업은 두 개의 디렉터리에 있는 전역 변수만 상속받습니다. 'VARIABLE3'는 상속받지 않습니다."
  inherit:
    variables:
      - VARIABLE1
      - VARIABLE2

추가 세부 정보:

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

`interruptible`

GitLab 12.3에서 도입됨.
trigger 작업의 지원이 GitLab 16.8에서 도입됨.

interruptible를 사용하여 동일한 참조에서 새로운 커밋을 시작하는 경우 작업이 완료되기 전에 작업을 취소하는 자동 취소 중복 파이프라인 기능을 구성합니다. 이 기능이 비활성화되어 있으면 키워드가 효과가 없습니다.

실행 중인 작업은 interruptible: true로 구성되어 있고 다음과 같을 때만 취소됩니다:

언제나 interruptible: false로 구성된 작업이 시작되지 않음. interruptible: false로 설정된 작업이 시작된 후에는 전체 파이프라인이 더 이상 취소 가능하지 않습니다.
- 파이프라인이 하위 파이프라인을 트리거했지만 하위 파이프라인에 아직 interruptible: false인 작업이 시작되지 않은 경우, 하위 파이프라인도 취소됩니다.
새로운 파이프라인은 새로운 변경 내용을 갖는 커밋을 위한 것입니다. 자동 취소 중복 파이프라인 기능은 같은 커밋에 대한 파이프라인을 실행하기 위해 UI에서 파이프라인 실행을 선택하는 경우에는 영향을 미치지 않습니다.

아직 시작되지 않은 작업은 구성에 관계없이 언제나 interruptible: true로 간주됩니다. interruptible 구성은 작업이 시작된 후에만 고려됩니다.

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

가능한 입력 값:

true 또는 false (기본값).

interruptible의 예시:

stages:
  - stage1
  - stage2
  - stage3

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

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

step-3:
  stage: stage3
  script:
    - echo "step-2가 취소할 수 없기 때문에 이 작업은 결코 취소되지 않습니다. 그럼에도 불구하고 취소 가능하다고 설정되어 있습니다."
  interruptible: true

이 예시에서 새로운 파이프라인은 다음과 같습니다:

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

추가 세부 정보:

빌드와 같이 작업이 시작된 후에 안전하게 취소될 수 있는 경우에만 interruptible: true를 설정하십시오. 일반적으로 배포 작업은 취소되지 않도록 해야 합니다.
파이프라인이 자동으로 취소되지 않게 하려면 파이프라인의 첫 번째 단계에 interruptible: false로 선택적 매뉴얼 작업을 추가할 수 있습니다. 사용자가 작업을 시작한 후에는 자동 취소 중복 파이프라인 기능으로 파이프라인을 취소할 수 없습니다.
트리거 작업에서 interruptible을 사용하는 경우:
- 트리거된 하위 파이프라인에는 절대 영향을 미치지 않습니다.
- workflow:auto_cancel이 conservative로 설정된 경우, 트리거 작업의 interruptible 구성에는 영향을 미치지 않습니다.
- workflow:auto_cancel이 interruptible로 설정된 경우, interruptible: true로 설정된 트리거 작업은 자동으로 취소될 수 있습니다.

`needs`

GitLab 12.2에서 도입됨.
GitLab 12.3에서 needs 배열의 최대 작업 수가 5개에서 50개로 증가함.
GitLab 12.8에서 needs: []가 즉시 시작을 가능하게 함.
GitLab 14.2에서 도입됨. 구성 중인 작업과 동일한 단계의 작업을 참조할 수 있습니다.

needs를 사용하여 작업을 순서에 관계없이 실행할 수 있습니다. needs를 사용하는 작업 사이의 관계는 directed acyclic graph로 시각화할 수 있습니다.

스테이지 순서를 무시하고 일부 작업을 다른 작업이 완료되기를 기다리지 않고 실행할 수 있습니다. 여러 스테이지에서의 작업은 동시에 실행될 수 있습니다.

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

가능한 입력 값:

작업 배열.
작업이 파이프라인이 생성되자마자 시작하도록 빈 배열([]).

needs의 예시:

linux:build:
  stage: build
  script: echo "리눅스 빌드 중..."

mac:build:
  stage: build
  script: echo "맥 빌드 중..."

lint:
  stage: test
  needs: []
  script: echo "린팅 중..."

linux:rspec:
  stage: test
  needs: ["linux:build"]
  script: echo "리눅스에서 rspec 실행 중..."

mac:rspec:
  stage: test
  needs: ["mac:build"]
  script: echo "맥에서 rspec 실행 중..."

production:
  stage: deploy
  script: echo "프로덕션 실행 중..."
  environment: production

이 예시에서 실행 경로는 다음과 같습니다:

린터: lint 작업은 needs: []로 인해 완료를 기다리지 않고 즉시 실행됩니다.
리눅스 경로: linux:rspec 작업은 linux:build 작업이 완료되면 즉시 실행되며, mac:build가 완료되기를 기다리지 않습니다.
macOS 경로: mac:rspec 작업은 mac:build 작업이 완료되면 즉시 실행되며, linux:build가 완료되기를 기다리지 않습니다.
이전 모든 작업(linux:build, linux:rspec, mac:build, mac:rspec)이 완료되면 production 작업이 즉시 실행됩니다.

추가 세부 정보:

단일 작업에서 needs 배열에 있는 작업의 최대 수는 제한됩니다:
- GitLab.com의 경우, 제한은 50입니다. 자세한 내용은 issue 350398을 참조하십시오.
- Self-managed 인스턴스의 경우, 기본 제한은 50입니다. 이 제한은 변경될 수 있습니다.
needs가 parallel 키워드를 사용하는 작업을 참조하는 경우, 모든 병렬 작업에 의존하며, 디폴트로 모든 병렬 작업의 아티팩트를 다운로드합니다. 아티팩트의 이름이 동일한 경우, 서로 덮어씁니다. 다운로드된 마지막 아티팩트만 저장됩니다.
- needs가 병렬화된 작업 중 일부 작업을 참조하도록 하려면, needs:parallel:matrix 키워드를 사용하십시오.
GitLab 14.1 및 이후에서는 설정 중인 작업과 동일한 스테이지 내 작업을 참조할 수 있습니다. 이 기능은 GitLab.com에서 활성화되어 있으며 운영에 준비되어 있습니다. Self-managed GitLab 14.2 및 이후에서는 이 기능이 기본적으로 사용할 수 있습니다.
GitLab 14.0 및 이전에서는 이전 스테이지의 작업을 참조할 수 있습니다. needs 키워드를 사용하는 모든 작업에 대해 스테이지를 명시적으로 정의해야 하며, 작업의 needs 섹션에 나열되어 있어야 합니다.
needs가 only, except, 또는 rules로 인해 파이프라인에 추가되지 않을 수도 있는 작업을 참조하는 경우, 파이프라인 생성에 실패할 수 있습니다. 실패한 파이프라인 생성을 해결하려면 needs:optional 키워드를 사용하십시오.
파이프라인에 needs: []로 시작하는 작업 및 .pre 스테이지의 작업이 있는 경우, 모두 파이프라인이 생성되는 즉시 시작됩니다. needs: []로 시작하는 작업은 즉시 시작되며, .pre 스테이지의 작업도 즉시 시작됩니다.

`needs:artifacts`

GitLab 12.6에서 도입됨.

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

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

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

가능한 입력값:

true (기본값) 또는 false

needs:artifacts의 예시:

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

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

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

이 예시에서:

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

추가 세부정보:

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

`needs:project`

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

GitLab 12.7에서 도입됨.

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

ref에 대한 파이프라인이 실행 중이면 needs:project를 사용하는 작업에서는 파이프라인이 완료될 때까지 기다리지 않습니다. 대신, 아티팩트는 지정된 작업의 최신 성공 실행에서 다운로드됩니다.

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

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

가능한 입력값:

needs:project: 네임스페이스와 그룹이 포함된 전체 프로젝트 경로.
job: 아티팩트를 다운로드할 작업.
ref: 아티팩트를 다운로드할 ref.
artifacts: 아티팩트를 다운로드하려면 true여야 합니다.

needs:project의 예시:

build_job:
  stage: build
  script:
    - ls -lhR
  needs:
    - project: namespace/group/project-name
      job: build-1
      ref: main
      artifacts: true
    - project: namespace/group/project-name-2
      job: build-2
      ref: main
      artifacts: true

이 예시에서 build_job은 group/project-name 및 group/project-name-2 프로젝트의 main 브랜치에서 최신 성공한 build-1 및 build-2 작업에서 아티팩트를 다운로드합니다.

GitLab 13.3 이상에서는 CI/CD 변수를 needs:project에서 사용할 수 있습니다.

build_job:
  stage: build
  script:
    - ls -lhR
  needs:
    - project: $CI_PROJECT_PATH
      job: $DEPENDENCY_JOB_NAME
      ref: $ARTIFACTS_DOWNLOAD_REF
      artifacts: true

추가 세부정보:

현재 프로젝트의 다른 파이프라인에서 아티팩트를 다운로드하려면 project를 현재 프로젝트와 동일하게 설정한 다음 현재 파이프라인과 다른 ref를 사용하세요. 동일한 ref에서 동시적인 파이프라인이 실행되면 아티팩트가 덮어씌워질 수 있습니다.
파이프라인을 실행하는 사용자는 그룹 또는 프로젝트에 대해 적어도 Reporter 역할이 있거나 그룹/프로젝트의 가시성이 공개이어야 합니다.
동일한 작업에서 trigger와 함께 needs:project를 사용할 수 없습니다.
다른 파이프라인에서 아티팩트를 다운로드할 때 needs:project 사용하는 작업은 필요한 작업이 완료될 때까지 기다리지 않습니다. 유향성 비순환 그래프 동작은 동일한 파이프라인의 작업에 한정됩니다. 필요한 작업이 아티팩트를 다운로드하기 전에 다른 파이프라인의 필요한 작업을 완료하도록 확인하세요.
parallel에서 실행되는 작업에서 아티팩트를 다운로드할 수 없습니다.
project, job, ref에서 CI/CD 변수를 사용할 수 있게 되었던 것은 GitLab 13.3에서 도입되었으며, 피처 플래그가 제거되었습니다.

관련 주제:

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

`needs:pipeline:job`

GitLab 13.7에서 도입됨.

하위 파이프라인은 해당 상위-하위 파이프라인 계층 구조 내의 상위 파이프라인 또는 다른 하위 파이프라인에서 작업에서 아티팩트를 다운로드할 수 있습니다.

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

가능한 입력값:

needs:pipeline: 파이프라인 ID. 동일한 상위-하위 파이프라인 계층 구조 내에 존재해야 합니다.
job: 아티팩트를 다운로드할 작업.

needs:pipeline:job의 예시:

상위 파이프라인 (.gitlab-ci.yml):

create-artifact:
  stage: build
  script: echo "샘플 아티팩트" > artifact.txt
  artifacts:
    paths: [artifact.txt]
  
child-pipeline:
  stage: test
  trigger:
    include: child.yml
    strategy: depend
  variables:
    PARENT_PIPELINE_ID: $CI_PIPELINE_ID

하위 파이프라인 (child.yml):

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

이 예시에서 상위 파이프라인의 create-artifact 작업이 아티팩트를 생성합니다. child-pipeline 작업이 하위 파이프라인을 트리거하고 CI_PIPELINE_ID 변수를 새로운 PARENT_PIPELINE_ID 변수로 하위 파이프라인에 전달합니다. 하위 파이프라인은 그 변수를 사용하여 상위 파이프라인에서 아티팩트를 다운로드할 수 있습니다.

추가 세부정보:

pipeline 속성은 현재 파이프라인 ID($CI_PIPELINE_ID)를 허용하지 않습니다. 현재 파이프라인의 작업에서 아티팩트를 다운로드하려면 needs:artifacts을 사용하세요.

`needs:optional`

GitLab 13.10에서 도입되었습니다.
피처 플래그 제거는 GitLab 14.0에 있었습니다.

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

rules, only, or except 및 include로 추가된 작업은 항상 파이프라인에 추가되지 않을 수 있습니다. GitLab은 파이프라인을 시작하기 전에 needs 연결을 확인합니다.

needs 항목에 optional: true가 있고 필요한 작업이 파이프라인에 있는 경우, 작업은 시작하기 전에 해당 작업이 완료될 때까지 대기합니다.
필요한 작업이 없는 경우, 다른 모든 요구 사항이 충족되면 작업을 시작할 수 있습니다.
needs 섹션이 선택적 작업만 포함하고 파이프라인에 추가되지 않은 경우, 작업은 즉시 시작합니다 (빈 needs 항목과 같이: needs: []).
필요한 작업이 optional: false인 경우이지만 파이프라인에 추가되지 않은 경우, 파이프라인은 시작할 수 없으며 다음과 유사한 오류가 발생합니다: 'job1' 작업은 'job2' 작업이 필요하지만 파이프라인에 추가되지 않았습니다.

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

needs:optional의 예:

build-job:
  stage: build

test-job1:
  stage: test

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

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

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

이 예에서:

build-job, test-job1, 및 test-job2가 단계별로 시작됩니다.
브랜치가 기본 브랜치인 경우 test-job2가 파이프라인에 추가되며:
- deploy-job은 test-job1과 test-job2가 모두 완료될 때까지 대기합니다.
- review-job은 test-job2가 완료될 때까지 대기합니다.
브랜치가 기본 브랜치가 아닌 경우 test-job2가 파이프라인에 추가되지 않으며:
- deploy-job은 test-job1만 완료될 때까지 대기하며 누락된 test-job2를 기다리지 않습니다.
- review-job은 다른 필요 작업이 없으며 즉시 시작됩니다 (needs: []와 동시에).

`needs:pipeline`

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

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

가능한 입력:

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

needs:pipeline의 예:

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

추가 정보:

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`

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/로 변경합니다. 이 디렉터리는 artifact로 내보내어 GitLab Pages로 게시됩니다.

`pages:publish`

GitLab 16.1에서 도입.

pages 작업의 콘텐츠 디렉터리를 구성하기 위해 publish를 사용합니다.

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

가능한 입력: Pages 콘텐츠를 포함하는 디렉터리 경로.

publish의 예시:

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

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

`pages:pages.path_prefix`

Tier: Premium, Ultimate Offering: Self-managed Status: Experiment

Experiment로 GitLab 16.7에서 도입 하는 데 필요한 플래그인 pages_multiple_versions_setting이 기본적으로 비활성화됨(Merge Request).

Self-managed GitLab의 기본적으로 이 기능은 사용할 수 없습니다. 사용하려면 관리자가 pages_multiple_versions_setting이라는 피처 플래그를 활성화해야 합니다. GitLab.com 및 GitLab Dedicated에서는 이 기능을 사용할 수 없습니다. 이 기능은 아직 제품 환경에 사용할 준비가 되지 않았습니다.

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

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

가능한 입력:

유효한 URL 문자로 이루어진 문자열.
CI/CD 변수.
두 가지를 혼합한 것.

pages.path_prefix의 예시:

pages:
  stage: deploy
  script:
    - echo "${CI_PAGES_URL}/${CI_COMMIT_BRANCH}를 통해 접근 가능한 Pages"
  pages:
    path_prefix: "$CI_COMMIT_BRANCH"
  artifacts:
    paths:
    - public

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

`parallel`

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

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

여러 개의 러너가 있어야 하거나 하나의 러너가 동시에 여러 작업을 실행하도록 구성되어야 합니다.

병렬로 실행되는 작업은 job_name 1/N부터 job_name N/N까지 순차적으로 이름이 지정됩니다.

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

가능한 입력:

1부터 200까지의 숫자 값.

parallel의 예시:

test:
  script: rspec
  parallel: 5

이 예시는 병렬로 실행되는 test 1/5에서 test 5/5까지의 5개의 작업을 생성합니다.

추가 세부 정보:

parallel 작업마다 CI_NODE_INDEX 및 CI_NODE_TOTAL 사전 정의된 CI/CD 변수가 설정됩니다.
parallel을 사용하는 작업이 있는 파이프라인은:
- 사용 가능한 러너보다 병렬로 더 많은 작업을 생성할 수 있습니다. 초과 작업은 대기 중인 상태로 표시되어 사용 가능한 러너를 기다립니다.
- 너무 많은 작업을 생성하여 파이프라인이 job_activity_limit_exceeded 오류로 실패할 수 있습니다. 활성 파이프라인에서 존재할 수 있는 최대 작업 수는 인스턴스 수준에서 제한됩니다.

관련 주제:

대규모 작업을 병렬로 실행.

`parallel:matrix`

GitLab 13.3에서 도입.
작업 네이밍 스타일이 GitLab 13.4에서 개선되었습니다.
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]
```

`release`

GitLab 13.2에 도입되었습니다.

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 예시:

프로젝트에 새로운 태그가 추가될 때 릴리스를 생성하는 경우:

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

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

동시에 릴리스와 새로운 태그를 생성하려면 rules은 작업을 새로운 태그에 대해서만 실행되도록 구성하면 안 됩니다. 시맨틱 버전 예시:

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

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

릴리스의 긴 설명입니다.

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

가능한 입력값:

긴 설명을 담은 문자열.
설명이 포함된 파일의 경로. GitLab 13.7에서 도입되었습니다.
- 파일 위치는 프로젝트 디렉터리($CI_PROJECT_DIR)를 기준으로 상대적이어야 합니다.
- 파일이 심볼릭 링크인 경우, 이는 $CI_PROJECT_DIR에 있어야 합니다.
- ./path/to/file과 파일 이름에 공백이 포함되어서는 안 됩니다.

release:description 예시:

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

추가 정보:

description은 release-cli를 실행하는 쉘에 의해 평가됩니다. CI/CD 변수를 사용하여 설명을 정의할 수 있지만, 일부 쉘은 변수를 참조하는 데 다른 구문을 사용할 수 있습니다. 마찬가지로, 일부 쉘은 특수 문자를 이스케이핑해야 할 수도 있습니다. 예를 들어, 역따옴표(`)는 백슬래시(\)로 이스케이핑해야 할 수 있습니다.

`release:ref`

릴리스의 tag_name이 아직 존재하지 않을 경우 릴리스를 위한 ref.

Keyword type: Job keyword. 작업의 일부로만 사용할 수 있습니다.

가능한 입력값:

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

`release:milestones`

릴리스가 연관된 각 마일스톤의 제목입니다.

`release:released_at`

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

가능한 입력값:

따옴표로 묶인 ISO 8601 형식의 날짜.

release:released_at의 예시:

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

추가 정보:

정의되지 않은 경우, 현재 날짜와 시간이 사용됩니다.

`release:assets:links`

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

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

release-cli 버전 v0.4.0 이상이 필요합니다.

release:assets:links의 예시:

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

`resource_group`

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

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

예를 들어, 동일한 리소스 그룹에 속하는 여러 작업이 동시에 대기 중인 경우 작업 중 하나만 시작됩니다. 다른 작업은 resource_group이 무료 상태가 될 때까지 대기합니다.

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

프로세스 모드를 선택하여 배포 환경에 맞게 작업 동시성을 전략적으로 제어할 수 있습니다. 기본 프로세스 모드는 unordered입니다. 리소스 그룹의 프로세스 모드를 변경하려면 API를 사용하여 기존 리소스 그룹을 편집하는 요청을 보내세요.

환경 당 여러 리소스 그룹을 정의할 수 있습니다. 예를 들어, 물리적 장치로 배포하는 경우 여러 물리적 장치가 있을 수 있습니다. 각 장치는 배포될 수 있지만 한 번에 한 장치당 하나의 배포만 발생할 수 있습니다.

Keyword type: Job keyword. 작업의 일부로만 사용할 수 있습니다.

가능한 입력값:

문자, 숫자, -, _, /, $, {, }, ., 스페이스만 가능합니다. /로 시작하거나 끝날 수 없습니다. CI/CD 변수는 지원됩니다.

resource_group의 예시:

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

이 예시에서 두 개의 deploy-to-production 작업이 서로 다른 파이프라인에서 동시에 실행될 수 없습니다. 결과적으로, 프로덕션 환경으로의 동시 배포를 방지할 수 있습니다.

관련 주제:

크로스 프로젝트/상위-하위 파이프라인의 파이프라인 수준 동시성 제어.

`retry`

작업이 실패한 경우 작업이 몇 번 다시 시도되는지를 구성하기 위해 retry를 사용하세요. 정의되지 않은 경우, 기본값은 0이고 작업은 다시 시도하지 않습니다.

작업이 실패하면 해당 작업은 성공할 때까지 또는 최대 재시도 횟수에 도달할 때까지 최대 두 번 더 처리됩니다.

기본적으로 모든 종류의 실패는 작업이 다시 시도되도록 합니다. 특정 종류의 실패 선택을 위해 retry:when 또는 retry:exit_codes를 사용하세요.

Keyword type: Job keyword. 작업의 일부로만 사용할 수 있습니다.

가능한 입력값:

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일 수 있습니다.

Keyword type: Job keyword. 작업의 일부로만 사용할 수 있습니다.

가능한 입력값:

단일 실패 유형 또는 여러 실패 유형으로 이루어진 배열:

always: 모든 실패에 대해 재시도 (기본값).
unknown_failure: 실패 이유가 알려지지 않은 경우 재시도.
script_failure: 다음과 같은 경우에 재시도:
- 스크립트 실패
- 러너가 Docker 이미지를 가져오지 못한 경우. docker, docker+machine, kubernetes executors에 대해.
api_failure: API 실패시 재시도.
stuck_or_timeout_failure: 작업이 멈추거나 시간 초과된 경우 재시도.
runner_system_failure: 러너 시스템 오류가 있는 경우 재시도 (예: 작업 설정 실패).
runner_unsupported: 러너가 지원되지 않는 경우 재시도.
stale_schedule: 지연된 작업이 실행되지 못한 경우 재시도.
job_execution_timeout: 작업에 대해 설정된 최대 실행 시간을 초과한 경우 재시도.
archived_failure: 작업이 보관되어 실행할 수 없는 경우 재시도.
unmet_prerequisites: 작업이 사전 작업을 완료하지 못한 경우 재시도.
scheduler_failure: 스케줄러가 작업을 러너에 할당하지 못한 경우 재시도.
data_integrity_failure: 알 수 없는 작업 문제가 있는 경우 재시도.

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

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

러너 시스템 오류 외의 종류의 실패가 발생한 경우 작업은 재시도되지 않습니다.

retry:when의 예시 (여러 실패 유형):

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

`retry:exit_codes`

Introduced in GitLab 16.10 with a flag named ci_retry_on_exit_codes. 기본으로 비활성화됩니다.

Self-managed GitLab에서는 이 기능이 기본으로 제공되지 않습니다. 이를 사용하려면 관리자가 ci_retry_on_exit_codes라는 feature flag를 활성화할 수 있습니다.

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

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

가능한 입력:

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

retry:exit_codes 예시:

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

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

관련 주제:

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

`rules`

Introduced in GitLab 12.3.

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

Rules는 파이프라인이 생성될 때 순서대로 평가되며 첫 번째 일치 항목까지 평가됩니다. 일치 항목을 찾으면 작업은 구성에 따라 파이프라인에 포함되거나 제외됩니다.

Rules에서는 job이 실행되기 전에 rules가 평가되기 때문에 job 스크립트에서 생성된 dotenv 변수를 사용할 수 없습니다.

rules는 only/except을 대체하며 동일한 job에서 둘을 함께 사용할 수 없습니다. 두 개 키워드를 동시에 구성하면 GitLab에서 key may not be used with rules 오류가 반환됩니다.

rules는 다음과 같이 정의된 규칙의 배열을 허용합니다:

if
changes
exists
allow_failure
variables
when

복합 규칙에 대해 다중 키워드를 함께 사용할 수 있습니다.

작업은 파이프라인에 추가됩니다:

if, changes, 또는 exists 규칙이 일치하고 또한 when: on_success (기본값), when: delayed, 또는 when: always가 있는 경우.
when: on_success, when: delayed, 또는 when: always만 있는 경우.

작업은 파이프라인에 추가되지 않습니다:

규칙이 일치하지 않는 경우.
규칙이 일치하고 when: never가 있는 경우.

!reference 태그를 사용하여 다른 작업에서 rules 구성을 재사용할 수 있습니다.

`rules:if`

rules:if 구문을 사용하여 작업을 파이프라인에 추가할 조건을 지정합니다:

if 문이 true이면 작업을 파이프라인에 추가합니다.
if 문이 true이지만 when: never와 함께 결합된 경우 작업을 파이프라인에 추가하지 않습니다.
if 문이 하나도 true가 아니면 작업을 파이프라인에 추가하지 않습니다.

키워드 유형: Job 및 Pipeline 구체적인. 작업의 행동을 구성하는 데 사용하거나 workflow와 함께 사용하여 파이프라인 동작을 구성할 수 있습니다.

가능한 입력:

CI/CD variable expression.

rules:if 예시:

job:
  script: echo "Hello, Rules!"
  rules:
    - if: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^feature/ && $CI_MERGE_REQUEST_TARGET_BRANCH_NAME != $CI_DEFAULT_BRANCH
      when: never
    - if: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ /^feature/
      when: manual
      allow_failure: true
    - if: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME

추가 정보:

일치하는 규칙이 있고 when이 정의되어 있지 않으면 규칙은 job에 대해 정의된 when을 사용하며, 정의되지 않은 경우 기본값으로 on_success를 사용합니다.
GitLab 14.5 및 이전 버전에서는 규칙당 when을 한 번 정의하거나 job 레벨에서 한 번 정의할 수 있었으며, 모든 규칙에 적용되는 job 레벨에서의 when과 규칙 내의 when을 혼합할 수 없었습니다.
GitLab 14.6 이후, job 레벨에서의 when을 규칙 내의 when과 혼합할 수 있습니다. rules에서의 when 설정이 job 레벨의 when보다 우선합니다.
script 섹션의 변수와 달리, 규칙 표현식의 변수는 항상 $VARIABLE로 형식화됩니다.
- rules:if와 함께 include를 사용하여 조건부로 다른 구성 파일을 포함할 수 있습니다.
=~ 및 !~ 표현식의 오른쪽에 있는 CI/CD 변수는 정규 표현식으로 평가됩니다.

관련 주제:

`rules:changes`

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

rules: changes는 branch pipelines 또는 merge request pipelines와 함께만 사용해야합니다. rules: changes는 다른 파이프라인 유형과 함께 사용할 수 있지만 rules: changes는 항상 새로운 브랜치 파이프라인이거나 Git push 이벤트가 없는 경우에는 항상 true로 평가됩니다. 태그 파이프라인, 예약된 파이프라인 및 매뉴얼 파이프라인과 같은 파이프라인에는 Git push 이벤트가 연결되어 있지 않습니다. 이러한 경우에는 rules: changes: compare_to를 사용하여 비교할 브랜치를 지정하십시오.

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

가능한 입력:

파일 경로를 포함하는 배열. GitLab 13.6 이상에서는 파일 경로에 변수를 포함할 수 있습니다. 파일 경로 배열은 rules:changes:paths에도 있을 수 있습니다.
와일드카드 경로:
- 단일 디렉터리에 대한 경로, 예: path/to/directory/*.
- 디렉터리 및 해당 하위 디렉터리에 대한 경로, 예: path/to/directory/**/*.
동일한 확장자 또는 여러 확장자를 가진 모든 파일에 대한 와일드카드 glob 경로, 예: *.md 또는 path/to/directory/*.{rb,py,sh}.
루트 디렉터리 또는 모든 디렉터리에있는 파일에 대한 와일드카드 경로, 큰따옴표로 묶인다. 예: "*.json" 또는 "**/*.json".

rules:changes의 예:

docker build:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      changes:
        - Dockerfile
      when: manual
      allow_failure: true

파이프라인이 Merge Request 파이프라인인 경우, Dockerfile의 변경 사항을 확인합니다.
Dockerfile이 변경되었을 경우, 작업을 매뉴얼 작업으로 파이프라인에 추가하고 작업이 트리거되지 않더라도 파이프라인이 계속 실행됩니다(allow_failure: true).
rules:changes 섹션 당 최대 50가지의 패턴 또는 파일 경로를 정의할 수 있습니다.
Dockerfile이 변경되지 않았을 경우, 어떤 파이프라인에도 작업을 추가하지 않습니다(when: never와 동일함).
rules:changes:paths는 하위 키가 없는 rules:changes와 동일합니다.

추가 세부 정보:

rules: changes는 only: changes 및 except: changes와 동일한 방식으로 작동합니다.
Glob 패턴은 Ruby의 File.fnmatch과 flagsFile::FNM_PATHNAME | File::FNM_DOTMATCH | File::FNM_EXTGLOB로 해석됩니다.
except:changes와 유사한 규칙을 구현하려면 when: never를 사용할 수 있습니다.
changes는 일치하는 파일 중 하나라도 변경되었을 경우 true로 해석합니다(OR 연산).

관련 주제:

rules: changes를 사용할 때 작업 또는 파이프라인이 예상치 않게 실행되는 문제.

`rules:changes:paths`

GitLab 15.2에서 도입.

rules:changes를 사용하여 특정 파일의 변경 사항을 확인하여 작업을 파이프라인에 추가할 때 지정하고, rules:changes:paths를 사용하여 해당 파일을 지정합니다.

rules:changes:paths는 하위 키가 없는 rules:changes를 사용하는 것과 동일합니다. 모든 추가 세부 정보와 관련 주제는 동일합니다.

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

가능한 입력:

파일 경로의 배열. 파일 경로에 변수를 포함할 수 있습니다.

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에서 도입 플래그 named ci_rules_changes_compare와 함께. 기본적으로 활성화됩니다.
GitLab 15.5에서 일반적으로 사용 가능. 피처 플래그 ci_rules_changes_compare가 제거되었습니다.

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

키워드 유형: Job 키워드. 작업의 일부로만 사용할 수 있습니다. rules:changes:paths와 결합하여 사용해야 합니다.

가능한 입력:

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

rules:changes:compare_to의 예:

docker build:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      changes:
        paths:
          - Dockerfile
        compare_to: 'refs/heads/branch1'

이 예에서 docker build 작업은 Dockerfile이 변경되었으며 파이프라인 소스가 Merge Request 이벤트인 경우에만 포함됩니다.

`rules:exists`

GitLab 12.4에서 소개되었습니다.
CI/CD 변수 지원이 GitLab 15.6에서 소개되었습니다.

exists를 사용하여 리포지터리에 특정 파일이 있는 경우 작업을 실행합니다.

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

가능한 입력:

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

rules:exists 예시:

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

Dockerfile이 리포지터리의 어느 곳이든 존재하는 경우 job가 실행됩니다.

추가 세부 정보:

Glob 패턴은 Ruby의 File.fnmatch과 함께 flags File::FNM_PATHNAME | File::FNM_DOTMATCH | File::FNM_EXTGLOB로 해석됩니다.
성능상의 이유로 GitLab은 exists 패턴이나 파일 경로에 대해 최대 10,000회의 확인을 수행합니다. 10,000번째 확인 이후에는 패턴화된 glob은 항상 일치합니다. 다시 말하면, exists 규칙은 10,000개 이상의 파일이 있는 프로젝트인 경우, 또는 10,000개 미만의 파일이 있지만 exists 규칙이 10,000회 이상 확인될 경우 항상 일치한다고 가정합니다.
rules:exists 섹션당 최대 50개의 패턴이나 파일 경로를 정의할 수 있습니다.
exists는 나열된 파일 중 하나라도 발견되면 true로 해석됩니다 (OR 연산).

`rules:allow_failure`

GitLab 12.8에서 소개되었습니다.

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

매뉴얼 작업과 allow_failure: true를 함께 사용할 수도 있습니다. 파이프라인은 매뉴얼 작업의 결과를 기다리지 않고 계속 실행됩니다. 또한 allow_failure: false는 규칙에서 when: manual과 결합되면 매뉴얼 작업이 실행될 때까지 파이프라인을 기다리도록 합니다.

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

가능한 입력:

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

rules:allow_failure 예시:

job:
  script: echo "안녕, 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`

피처 플래그introduce_rules_with_needs와 함께 GitLab 16.0에서 소개되었습니다. 기본적으로 비활성화되어 있습니다.
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 "기본 브랜치이므로 프로덕션 버전 빌드 중..."

specs:
  stage: test
  needs: ['build-dev']
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      needs: ['build-prod']
    - when: on_success # 다른 경우에 작업 실행
  script: echo "기본적으로 dev 스펙 실행, 또는 기본 브랜치인 경우 prod 스펙 실행..."

이 예시에서:

기본 브랜치가 아닌 브랜치에서 파이프라인이 실행되면 specs 작업은 build-dev 작업이 필요합니다(기본 동작).
기본 브랜치에서 파이프라인이 실행되고, 따라서 규칙이 조건과 일치하는 경우 specs 작업은 대신 build-prod 작업이 필요합니다.

추가 세부 정보:

규칙에서의 needs는 작업 수준에서 정의된 needs를 재정의합니다. 재정의된 경우, 작동 방식은 작업 수준의 needs과 동일합니다.
규칙에서의 needs는 artifacts와 optional을 허용합니다.

`rules:variables`

GitLab 13.7에서 소개되었습니다.
GitLab 13.10에서 피처 플래그가 제거되었습니다.

rules에서 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 "스크립트 실행 시 $DEPLOY_VARIABLE를 인자로 사용"
    - echo "$IS_A_FEATURE이(가) 있을 때 다른 스크립트 실행"

`rules:interruptible`

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

interruptible를 rules에 사용하여 특정 조건에 대한 작업의 interruptible 값을 업데이트합니다.

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

가능한 입력값:

true 또는 false.

rules:interruptible의 예시:

job:
  script: echo "안녕하세요, Rules!"
  interruptible: true
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      interruptible: false  # 작업 수준에서 정의된 interruptible을 재정의합니다.
    - when: on_success

추가 세부 정보:

rule-level rules:interruptible은 작업 수준의 interruptible을 재정의하며 특정 규칙이 작업을 트리거하는 경우에만 적용됩니다.

`script`

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

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

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

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

단일 라인 명령.
여러 줄에 걸친 긴 명령.
YAML 앵커.

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

script의 예시:

job1:
  script: "bundle exec rspec"

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

추가 세부 정보:

script에서 특수 문자를 사용할 때에는 작은 따옴표(‘)나 큰 따옴표(“)를 사용해야 합니다.

관련 주제:

0이 아닌 종료 코드 무시.
작업 로그를 쉽게 검토할 수 있도록 작업 로그에 색 코드 사용.
사용자 정의 가능한 접기 가능한 섹션 생성 작업 로그 출력을 간소화합니다.

`secrets`

티어: Premium, Ultimate 오퍼링: GitLab.com, 셀프매니지드, GitLab Dedicated

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

secrets를 사용하여 CI/CD 비밀을 지정하여 다음을 수행합니다:

외부 시크릿 공급자에서 검색합니다.
CI/CD 변수로 작업에서 사용할 수 있도록 만듭니다 (기본적으로 file 유형).

`secrets:vault`

GitLab 13.4 및 GitLab Runner 13.4에서 도입되었습니다.

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

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

가능한 입력값:

engine:name: 시크릿 엔진의 이름.
engine:path: 시크릿 엔진의 경로.
path: 비밀의 경로.
field: 비밀이 저장된 필드의 이름.

secrets:vault의 예시:

모든 세부 정보를 명시적으로 지정하고 KV-V2 시크릿 엔진을 사용하는 경우:

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

이 구문을 간소화할 수 있습니다. 간단한 구문을 사용하려면 engine:name 및 engine:path 모두 기본값인 kv-v2가 됩니다:

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

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

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

`secrets:gcp_secret_manager`

GitLab 16.8 및 GitLab Runner 16.8에서 도입되었습니다.

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

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

가능한 입력값:

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에서 제공되는 비밀을 지정합니다.

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

가능한 입력값:

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`

History

Introduced in GitLab 14.1 and GitLab Runner 14.1.

secrets:file을 사용하여 시크릿을 file 또는 variable 유형의 CI/CD 변수로 저장합니다.

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

소프트웨어가 file 유형의 CI/CD 변수를 사용할 수 없는 경우 file: false를 설정하여 시크릿 값을 직접 변수에 저장할 수 있습니다.

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

가능한 입력값:

true (기본값) 또는 false

secrets:file의 예시:

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

추가 정보:

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

`secrets:token`

History

Introduced in GitLab 15.8, controlled by the Limit JSON Web Token (JWT) access setting.
Made always available and Limit JSON Web Token (JWT) access setting removed in GitLab 16.0.

secrets:token을 사용하여 Vault와의 인증에 사용할 토큰을 명시적으로 선택합니다.

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

가능한 입력값:

ID 토큰의 이름

secrets:token의 예시:

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

추가 정보:

token 키워드가 설정되지 않은 경우 첫 번째 ID 토큰이 사용됩니다.

`services`

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

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

가능한 입력값: 이러한 형식 중 하나인 서비스 이미지의 이름(필요한 경우 레지스트리 경로 포함):

<image-name> (가장 최신의 latest 태그와 동일)
<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`

History

Introduced in GitLab 16.7. Requires GitLab Runner 16.7 or later.
user input option introduced in GitLab 16.8.

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

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

가능한 입력값:

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

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

services:docker의 예시:

arm-sql-job:
  script: echo "Run sql tests in service container"
  image: ruby:2.6
  services:
    - name: super/sql:experimental
      docker:
        platform: arm64/v8
        user: dave

추가 정보:

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

`services:pull_policy`

History

Introduced in GitLab 15.1 with a flag named ci_docker_image_pull_policy. Disabled by default.
Enabled on GitLab.com and Self-managed in GitLab 15.2.
Generally available in GitLab 15.4. 피처 플래그 ci_docker_image_pull_policy removed.
Requires GitLab Runner 15.1 or later.

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

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

가능한 입력값:

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

services:pull_policy의 예시:

job1:
  script: echo "A single pull policy."
  services:
    - name: postgres:11.6
      pull_policy: if-not-present

job2:
  script: echo "Multiple pull policies."
  services:
    - name: postgres:11.6
      pull_policy: [always, if-not-present]

추가 정보:

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

관련 주제:

`stage`

stage을 사용하여 작업이 실행되는 stage를 정의합니다. 동일한 stage에있는 작업은 병렬로 실행될 수 있습니다 (자세한 내용은 추가 정보 참조).

stage이 정의되지 않은 경우 작업은 기본적으로 test stage를 사용합니다.

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

가능한 입력값: 문자열, 즉,

기본 stage.
사용자 정의 stages.

stage 예시:

stages:
  - build
  - test
  - deploy

job1:
  stage: build
  script:
    - echo "This job compiles code."

job2:
  stage: test
  script:
    - echo "This job tests the compiled code. It runs when the build stage completes."

job3:
  script:
    - echo "This job also runs in the test stage".

job4:
  stage: deploy
  script:
    - echo "This job deploys the code. It runs when the test stage completes."
  environment: production

추가 정보:

작업이 서로 다른 러너에서 실행되는 경우 병렬로 실행될 수 있습니다.
러너가 하나뿐인 경우 러너의 concurrent 설정 가 1보다 큰 경우 작업을 병렬로 실행할 수 있습니다.

`stage: .pre`

GitLab 12.4에서 도입.

.pre stage을 사용하여 job을 파이프라인의 시작에서 실행하도록합니다. .pre은 항상 파이프라인의 첫 번째 stage입니다. 사용자 정의 stages는 .pre 이후에 실행됩니다. stages에서 .pre을 정의 할 필요는 없습니다.

파이프라인에 .pre 또는 .post stage의 작업만 포함 된 경우 실행되지 않습니다. 다른 stage에 적어도 하나의 다른 작업이 있어야합니다.

키워드 유형: 작업의 stage 키워드와 함께만 사용할 수 있습니다.

stage: .pre 예시:

stages:
  - build
  - test

job1:
  stage: build
  script:
    - echo "This job runs in the build stage."

first-job:
  stage: .pre
  script:
    - echo "This job runs in the .pre stage, before all other stages."

job2:
  stage: test
  script:
    - echo "This job runs in the test stage."

`stage: .post`

GitLab 12.4에서 도입.

.post stage을 사용하여 job을 파이프라인의 끝에서 실행하도록합니다. .post 은 항상 파이프라인의 마지막 stage입니다. 사용자 정의 stages는 .post 이전에 실행됩니다. stages에서 .post을 정의 할 필요는 없습니다.

파이프라인에 .pre 또는 .post stage의 작업만 포함 된 경우 실행되지 않습니다. 다른 stage에 적어도 하나의 다른 작업이 있어야합니다.

키워드 유형: 작업의 stage 키워드와 함께만 사용할 수 있습니다.

stage: .post 예시:

stages:
  - build
  - test

job1:
  stage: build
  script:
    - echo "This job runs in the build stage."

last-job:
  stage: .post
  script:
    - echo "This job runs in the .post stage, after all other stages."

job2:
  stage: test
  script:
    - echo "This job runs in the test stage."

추가 정보:

파이프라인에 needs: []와 .pre stage의 작업이있는 경우, 파이프라인이 생성되는 즉시 모두 시작됩니다. needs: []가있는 작업은 즉시 시작되며 stage 구성을 무시합니다.

`tags`

GitLab 14.3에서 활성화 된 작업 당 50 개의 태그 제한.

tags를 사용하여 프로젝트에서 사용 가능한 모든 러너 디렉터리에서 특정 러너를 선택합니다.

러너를 등록할 때 러너의 태그를 지정할 수 있으며, 예를 들어 ruby, postgres, 또는 development와 같이 지정할 수 있습니다. 작업을 실행하기위해 작업에 지정된 모든 태그가있는 러너가 있어야합니다.

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

가능한 입력값:

태그 이름의 배열.
CI/CD 변수는 지원됩니다 GitLab 14.1 이후 버전에서.

tags 예시:

job:
  tags:
    - ruby
    - postgres

이 예에서 ruby 및 postgres 태그가 모두있는 러너 만 작업을 실행 할 수 있습니다.

추가 정보:

GitLab 14.3 이상에서 태그 수는 50 미만이어야합니다.

관련 주제:

`timeout`

GitLab 12.3에서 도입.

특정 작업에 대한 시간 제한을 구성하기 위해 timeout을 사용합니다. 작업이 제한 시간보다 오래 실행되면 작업이 실패합니다.

작업 레벨의 시간 제한은 프로젝트 레벨 시간 제한보다 길 수는 있지만 러너의 시간 제한보다 길 수는 없습니다.

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

가능한 입력값: 자연어로 작성된 시간 단위. 예를 들어 다음과 같습니다:

3600 seconds
60 minutes
한 시간

timeout 예시:

build:
  script: build.sh
  timeout: 3 hours 30 minutes

test:
  script: rspec
  timeout: 3h 30m

`trigger`

- resource_group 지원이 GitLab 13.9에서 도입되었습니다. - environment 지원이 GitLab 16.4에서 도입되었습니다.

trigger를 사용하여 작업이 “트리거 작업”임을 선언하여 다음 중 하나인 다운스트림 파이프라인을 시작합니다:

트리거 작업에서는 제한된 GitLab CI/CD 구성 키워드만 사용할 수 있습니다. 트리거 작업에서 사용할 수 있는 키워드는 다음과 같습니다:

allow_failure.
extends.
needs, 단, needs:project는 사용할 수 없습니다.
only 및 except.
rules.
stage.
trigger.
variables.
when (값이 on_success, on_failure, 또는 always인 경우에만).
resource_group.
environment.

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

가능한 입력값:

다중 프로젝트 파이프라인의 경우 다운스트림 프로젝트의 경로. CI/CD 변수는 GitLab 15.3 및 이후 버전에서 지원되지만 작업 수준의 보존 변수는 지원되지 않습니다. 또는 trigger:project를 사용하세요.
자식 파이프라인의 경우 trigger:include를 사용하세요.

trigger의 예시:

trigger-multi-project-pipeline:
  trigger: my-group/my-project

추가 상세 사항:

API를 사용하여 when:manual 트리거 작업을 시작할 수 없습니다.
GitLab 13.5 및 이후 버전에서는 trigger와 함께 when:manual을 동일한 작업에서 사용할 수 있습니다. GitLab 13.4 및 이전 버전에서는 함께 사용하면 jobs:#{job-name} when should be on_success, on_failure or always 오류가 발생합니다.
매뉴얼 트리거 작업을 실행하기 전에 CI/CD 변수를 직접 지정할 수 없습니다.
매뉴얼 파이프라인 변수 및 예약된 파이프라인 변수는 기본적으로 하위 파이프라인으로 전달되지 않습니다. 하위 파이프라인으로 이러한 변수를 전달하려면 trigger:forward를 사용하세요.
작업 수준의 보존 변수는 트리거 작업에서 사용할 수 없습니다.
환경 변수는 러너의 config.toml에서 정의된 환경 변수가 트리거 작업에서 사용되지 않으며 하위 파이프라인으로 전달되지 않습니다.

관련 주제:

다중 프로젝트 파이프라인 구성 예시.
특정 브랜치, 태그 또는 커밋에 대한 파이프라인을 실행하려면 트리거 토큰을 사용하여 파이프라인 트리거 API에 인증하면 됩니다. 트리거 토큰은 trigger 키워드와는 다릅니다.

`trigger:include`

trigger:include를 사용하여 작업이 “트리거 작업”임을 선언하여 자식 파이프라인을 시작합니다.

trigger:include:artifact를 사용하여 동적 자식 파이프라인을 트리거합니다.

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

가능한 입력값:

자식 파이프라인의 구성 파일 경로.

trigger:include의 예시:

trigger-child-pipeline:
  trigger:
    include: path/to/child-pipeline.gitlab-ci.yml

관련 주제:

자식 파이프라인 구성 예시.

`trigger:project`

trigger:project를 사용하여 작업이 “트리거 작업”임을 선언하여 다중 프로젝트 파이프라인을 시작합니다.

기본적으로 다중 프로젝트 파이프라인은 기본 브랜치에 대해 트리거됩니다. 다른 브랜치를 지정하려면 trigger:branch를 사용하세요.

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

가능한 입력값:

다운스트림 프로젝트의 경로. 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 작업이 하위 파이프라인이 완료될 때까지 success로 표시되도록 강제할 수 있습니다.

기본 설정인 trigger 작업이 하위 파이프라인이 생성되자마자 success로 표시되는 동작과는 다릅니다.

이 설정은 파이프라인 실행을 병렬이 아닌 선형으로 만듭니다.

trigger:strategy의 예제:

trigger_job:
  trigger:
    include: path/to/child-pipeline.yml
    strategy: depend

이 예제에서는 후속 단계의 작업이 시작되기 전에 트리거된 파이프라인이 성공적으로 완료되기를 기다립니다.

추가 세부 정보:

하위 파이프라인의 Optional manual jobs은 하위 파이프라인 또는 상위 트리거 작업의 상태에 영향을 주지 않습니다. 선택적 매뉴얼 작업을 실행하지 않고 하위 파이프라인을 성공적으로 완료할 수 있습니다.
하위 파이프라인의 Blocking manual jobs은 트리거 작업이 성공 또는 실패로 표시되기 전에 실행되어야 합니다. 트리거 작업은 매뉴얼 작업으로 인해 하위 파이프라인 상태가 waiting for manual action () 이면 pending () 상태를 보여줍니다. 기본적으로, 후속 단계의 작업은 트리거 작업이 완료될 때까지 시작되지 않습니다.
하위 파이프라인에 실패한 작업이 있지만, 작업이 allow_failure: true를 사용하는 경우, 하위 파이프라인은 성공으로 간주되고 트리거 작업은 success로 표시됩니다.

`trigger:forward`

History

Introduced in GitLab 14.9 with a flag named ci_trigger_forward_variables. Disabled by default.
Enabled on GitLab.com and Self-managed in GitLab 14.10.
Generally available in GitLab 15.1. 피처 플래그 ci_trigger_forward_variables removed.

trigger:forward를 사용하여 하위 파이프라인에 전달할 내용을 지정합니다. parent-child pipelines 및 multi-project pipelines에 대해 전달할 내용을 제어할 수 있습니다.

가능한 입력:

yaml_variables: true (기본값), 또는 false. true일 때, 트리거 작업에서 정의된 변수가 하위 파이프라인으로 전달됩니다.
pipeline_variables: true 또는 false (기본값). true일 때, manual pipeline variables 및 scheduled pipeline variables 가 하위 파이프라인으로 전달됩니다.

trigger:forward의 예제:

Run this pipeline manually, with the CI/CD variable MYVAR = my value:

variables: # default variables for each job
  VAR: value

# Default behavior:
# - VAR is passed to the child
# - MYVAR is not passed to the child
child1:
  trigger:
    include: .child-pipeline.yml

# Forward pipeline variables:
# - VAR is passed to the child
# - MYVAR is passed to the child
child2:
  trigger:
    include: .child-pipeline.yml
    forward:
      pipeline_variables: true

# Do not forward YAML variables:
# - VAR is not passed to the child
# - MYVAR is not passed to the child
child3:
  trigger:
    include: .child-pipeline.yml
    forward:
      yaml_variables: false

추가 세부 정보:

trigger:forward로 하위 파이프라인에 전달되는 CI/CD 변수는 가장 높은 우선 순위를 갖습니다. 동일한 이름을 가진 변수가 하위 파이프라인에서 정의된 경우, 해당 변수는 전달된 변수에 의해 덮어쓰입니다.

`variables`

작업에 대한 CI/CD 변수를 정의하기 위해 variables를 사용합니다.

키워드 유형: Global 및 job 키워드. 전역 수준 및 작업 수준에서 사용할 수 있습니다.

만약 variables를 global 키워드로 정의하면, 모든 작업의 기본 변수로 작동합니다. 파이프라인이 생성될 때 각 변수가 모든 작업 구성으로 복사됩니다. 작업에 이미 해당 변수가 정의되어 있는 경우, 작업 수준 변수가 우선합니다.

전역 수준에서 정의된 변수는 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 service containers에도 설정됩니다.
YAML로 정의된 변수는 민감하지 않은 프로젝트 구성을 위한 것입니다. 민감한 정보는 protected variables 또는 CI/CD secrets에 보관합니다.
Manual pipeline variables과 scheduled pipeline variables 는 기본적으로 하위 파이프라인으로 전달되지 않습니다. trigger:forward를 사용하여 하위 파이프라인에 이러한 변수들을 전달하세요.

관련 주제:

Predefined variables은 러너가 자동으로 생성하고 작업에서 사용 가능하게 하는 변수입니다.
변수를 사용하여 러너(runner) 동작을 구성할 수 있습니다.

`variables:description`

GitLab 13.7에서 소개되었습니다.

description 키워드를 사용하여 파이프라인 수준(전역) 변수에 설명을 정의합니다. 이 설명은 매뉴얼으로 파이프라인을 실행할 때 미리 입력된 변수 이름과 함께 표시됩니다.

키워드 유형: 전역 키워드. 작업 수준 변수에는 사용할 수 없습니다.

가능한 입력값:

문자열.

variables:description의 예시:

variables:
  DEPLOY_NOTE:
    description: "The deployment note. Explain the reason for this deployment."

추가 세부정보:

value 없이 사용하면 수동으로 트리거되지 않은 파이프라인에 변수가 존재하며, 기본값은 빈 문자열('')입니다.

`variables:value`

GitLab 13.7에서 소개되었습니다.

value 키워드를 사용하여 파이프라인 수준(전역) 변수의 값을 정의합니다. variables:description와 함께 사용되면 파이프라인을 매뉴얼으로 실행할 때 변수 값이 미리 입력됩니다.

키워드 유형: 전역 키워드. 작업 수준 변수에는 사용할 수 없습니다.

가능한 입력값:

문자열.

variables:value의 예시:

variables:
  DEPLOY_ENVIRONMENT:
    value: "staging"
    description: "The deployment target. Change this variable to 'canary' or 'production' if needed."

추가 세부정보:

variables:description를 사용하지 않고 사용하면 동작이 variables와 동일합니다.

`variables:options`

GitLab 15.7에서 소개되었습니다.

variables:options를 사용하여 파이프라인을 매뉴얼으로 실행할 때 UI에서 선택 가능한 값의 배열을 정의합니다.

variables:value와 함께 사용해야 하며, value로 정의된 문자열은:

options 배열의 문자열 중 하나여야 합니다.
기본 선택값입니다.

만약 description이 없으면, 이 키워드는 영향을 미치지 않습니다.

키워드 유형: 전역 키워드. 작업 수준 변수에는 사용할 수 없습니다.

가능한 입력값:

문자열 배열.

variables:options의 예시:

variables:
  DEPLOY_ENVIRONMENT:
    value: "staging"
    options:
      - "production"
      - "staging"
      - "canary"
    description: "The deployment target. Set to 'staging' by default."

`variables:expand`

GitLab 15.6에 ci_raw_variables_in_yaml_config라는 플래그로 도입되었습니다. 기본적으로 비활성화되어 있습니다.
GitLab 15.6에서 GitLab.com에 활성화되었습니다.
GitLab 15.7에서 자체 호스팅된 GitLab에 활성화되었습니다.
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입니다.

키워드 유형: 작업 키워드. 작업의 일부로 사용할 수 있습니다. workflow:rules에서도 when: always 및 when: never를 사용할 수 있습니다.

가능한 입력값:

on_success (기본값): 이전 단계에서의 작업 중에 실패한 작업이 없거나 allow_failure: true가 있는 경우에만 작업을 실행합니다.
on_failure: 이전 단계에서 최소한 하나의 작업이 실패한 경우에만 작업을 실행합니다. 이전 단계의 작업 중 allow_failure: true가 있는 작업은 항상 성공으로 간주됩니다.
never: 이전 단계의 작업 상태에 관계없이 작업을 실행하지 않습니다. rules 섹션이나 workflow: rules에서만 사용할 수 있습니다.
always: 이전 단계의 작업 상태에 관계없이 작업을 항상 실행합니다. workflow:rules에서도 사용할 수 있습니다.
manual: 수동으로 트리거될 때만 작업을 실행합니다.
delayed: 지정된 기간 동안 작업 실행을 지연합니다.

when 예시:

stages:
  - build
  - cleanup_build
  - test
  - deploy
  - cleanup

build_job:
  stage: build
  script:
    - make build

cleanup_build_job:
  stage: cleanup_build
  script:
    - cleanup build when failed
  when: on_failure

test_job:
  stage: test
  script:
    - make test

deploy_job:
  stage: deploy
  script:
    - make deploy
  when: manual
  environment: production

cleanup_job:
  stage: cleanup
  script:
    - cleanup after jobs
  when: always

이 예시에서 스크립트는:

build_job이 실패할 때에만 cleanup_build_job을 실행합니다.
cleanup_job은 항상 파이프라인의 마지막 단계로 실행합니다. 성공 또는 실패에 관계없이.
GitLab UI에서 매뉴얼으로 실행할 때에만 deploy_job을 실행합니다.

추가 세부정보:

GitLab 13.5 이후, when:manual을 trigger와 함께 사용할 수 있습니다. GitLab 13.4 이전에는 함께 사용하면 jobs:#{job-name} when should be on_success, on_failure or always라는 오류가 발생합니다.
when: manual의 기본 동작은 allow_failure이 true로 변경됩니다. 그러나 rules과 함께 when:manual을 사용하는 경우 allow_failure의 기본값은 false입니다.

관련 주제:

보다 동적인 작업 제어를 위해 rules에 when을 사용할 수 있습니다.
파이프라인이 시작될 때를 제어하기 위해 workflow에 when을 사용할 수 있습니다.

사용되지 않는 키워드

다음 키워드들은 더 이상 사용되지 않습니다.

참고: 이러한 키워드들은 여전히 하위 호환성을 보장하기 위해 사용할 수 있지만, 미래의 주요 마일스톤에서 제거될 수 있습니다.

전역으로 정의된 `image`, `services`, `cache`, `before_script`, `after_script`

image, services, cache, before_script 및 after_script을 전역으로 정의하는 것은 사용되지 않습니다. 이러한 키워드를 최상위 수준에서 사용하는 것은 여전히 가능하며, 하위 호환성을 보장하기 위해 미래의 마일스톤에서 제거될 수 있습니다.

대신 default를 사용하세요. 예를 들어:

default:
  image: ruby:3.0
  services:
    - docker:dind
  cache:
    paths: [vendor/]
  before_script:
    - bundle config set path vendor/bundle
    - bundle install
  after_script:
    - rm -rf tmp/

`only` / `except`

참고: only와 except는 사용되지 않으며 더 이상 개발되지 않습니다. 이러한 키워드들은 하위 호환성을 보장하기 위해 사용할 수 있지만, 미래의 마일스톤에서 제거될 수 있습니다. 파이프라인에 작업을 추가할 때 제어하려면 대신 rules을 사용하세요.

only 및 except를 사용하여 파이프라인에 작업을 추가할 때 다음을 사용할 수 있습니다.

작업이 실행되는 시기를 정의하려면 only를 사용합니다.
작업이 실행되지 않는 시기를 정의하려면 except를 사용합니다.

자세한 내용 및 예제는 only 및 except로 작업 실행 시기 지정을 참조하세요.

`only:refs` / `except:refs`

참고: only:refs와 except:refs는 사용되지 않으며 더 이상 개발되고 있지 않습니다. 이러한 키워드들은 하위 호환성을 보장하기 위해 사용할 수 있지만, 미래의 마일스톤에서 제거될 수 있습니다. 참조, 정규 표현식 또는 변수를 사용하여 파이프라인에 작업을 추가할 때는 대신 rules:if를 사용하세요.

only:refs 및 except:refs 키워드를 사용하여 브랜치 이름 또는 파이프라인 유형에 따라 파이프라인에 작업을 추가하는 것을 제어할 수 있습니다.

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

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

브랜치 이름, 예: main 또는 my-feature-branch.
브랜치 이름과 일치하는 정규 표현식, 예: /^feature-.*/.
다음의 키워드:
| 값 | 설명 | | ————————-|—————–| | api | 파이프라인 API에서 트리거된 파이프라인에 대한 키워드. | | branches | 파이프라인의 Git 참조가 브랜치인 경우. | | chat | GitLab ChatOps 명령어를 사용하여 생성된 파이프라인에 대한 키워드. | | external | GitLab 외의 CI 서비스를 사용한 경우. | | external_pull_requests | GitHub에서 외부 풀 리퀘스트가 생성되거나 업데이트된 경우 (자세한 내용은 외부 풀 리퀘스트용 파이프라인 참조). | | merge_requests | Merge Request이 생성되거나 업데이트된 경우. Merge Request 파이프라인, Merge된 결과 파이프라인 및 Merge Train을 활성화합니다. | | pipelines | API와 함께 CI_JOB_TOKEN을 사용하여 다중 프로젝트 파이프라인을 트리거하는 방법으로 작성된 다중 프로젝트 파이프라인 에 대한 키워드. | | pushes | git push 이벤트로 트리거된 파이프라인에 대한 키워드로, 브랜치 및 태그 모두 포함됩니다. | | schedules | 예약된 파이프라인에 대한 키워드. | | tags | 파이프라인의 Git 참조가 태그인 경우. | | triggers | 트리거 토큰을 사용하여 생성된 파이프라인에 대한 키워드. | | web | GitLab UI의 Run Pipeline을 선택하여 프로젝트의 Build > Pipelines 섹션에서 생성된 파이프라인에 대한 키워드. |

only:refs 및 except:refs의 예:

job1:
  script: echo
  only:
    - main
    - /^issue-.*/
    - merge_requests

job2:
  script: echo
  except:
    - main
    - /^stable-branch.*/
    - schedules

추가 세부 정보:

예약된 파이프라인에서도 only: branches로 구성된 작업이 실행됩니다. only: branches로 구성된 작업이 예약된 파이프라인에서 실행되지 않도록 하려면 except: schedules를 추가하세요.
다른 키워드 없이 사용하는 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는 사용되지 않으며 더 이상 개발되고 있지 않습니다. 이러한 키워드들은 하위 호환성을 보장하기 위해 사용할 수 있지만, 미래의 마일스톤에서 제거될 수 있습니다. 파이프라인에 작업을 추가할 때 CI/CD 변수의 상태를 기반으로 제어하기 위해 only:variables 또는 except:variables 키워드를 사용할 수 있습니다.

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

가능한 입력:

CI/CD 변수 식의 배열.

only:variables의 예:

deploy:
  script: cap staging deploy
  only:
    variables:
      - $RELEASE == "staging"
      - $STAGING

관련 주제:

only:variables 및 except:variables 예제.

`only:changes` / `except:changes`

only:variables and except:variables

only:changes 및 except:changes는 더 이상 활발히 개발되고 있지 않으며 폐기 대상입니다. 이러한 키워드는 역 호환성을 보장하기 위해 여전히 사용할 수 있지만, 향후 마일스톤에서 삭제될 수 있습니다. 파일을 수정하는 Git 푸시 이벤트 발생 시 작업을 추가 또는 건너뛰기하려면 rules:changes를 대신 사용하세요.

changes 키워드를 사용하여 다음 ref와 함께 파이프라인에서 사용하세요:

branches
external_pull_requests
merge_requests (merge request 파이프라인에서 only:changes 사용에 대한 추가 정보는 여기를 참조하세요)

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

가능한 입력: 파일의 경로를 포함한 배열

단일 디렉터리에 대한 와일드카드 경로, 예: 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 연산).
글로브 패턴은 Ruby의 File.fnmatch과 함께 flags File::FNM_PATHNAME | File::FNM_DOTMATCH | File::FNM_EXTGLOB로 해석됩니다.
branches, external_pull_requests, 또는 merge_requests 이외의 ref를 사용하는 경우 changes는 주어진 파일이 새로운지 여부를 판단할 수 없으며 항상 true를 반환합니다.
다른 ref와 함께 only: changes를 사용하는 경우 job은 변경 사항을 무시하고 항상 실행됩니다.
다른 ref와 함께 except: changes를 사용하는 경우 job은 변경 사항을 무시하고 절대로 실행되지 않습니다.

관련 주제:

`only:kubernetes` / `except:kubernetes`

only:kubernetes 및 except:kubernetes는 더 이상 활발히 개발되고 있지 않으며 폐기 대상입니다. 이러한 키워드는 역 호환성을 보장하기 위해 여전히 사용할 수 있지만, 향후 마일스톤에서 삭제될 수 있습니다. 프로젝트에 Kubernetes 서비스가 활성화된 경우 작업이 파이프라인에 추가되는지를 제어하려면 미리 정의된 CI/CD 변수인 CI_KUBERNETES_ACTIVE와 함께 rules:if를 사용하세요.

프로젝트에 Kubernetes 서비스가 활성화된 경우 작업이 파이프라인에 추가되는지 또는 제외되는지를 제어하려면 only:kubernetes 또는 except:kubernetes를 사용하세요.

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

가능한 입력:

kubernetes 전략은 active 키워드만 허용합니다.

only:kubernetes의 예:

deploy:
  only:
    kubernetes: active

이 예에서 deploy 작업은 프로젝트에서 Kubernetes 서비스가 활성화된 경우에만 실행됩니다.