• 키워드
• 전역 키워드
  • default
  • include
    • include:component
    • include:local
    • include:project
    • include:remote
    • include:template
    • include:inputs
  • stages
  • workflow
    • workflow:auto_cancel:on_new_commit
    • workflow:auto_cancel:on_job_failure
    • workflow:name
    • workflow:rules
    • workflow:rules:variables
    • workflow:rules:auto_cancel
• 해더 키워드
  • spec
    • spec:inputs
      • spec:inputs:default
      • spec:inputs:description
      • spec:inputs:options
      • spec:inputs:regex
      • spec:inputs:type
• 작업 키워드
  • after_script
  • allow_failure
    • allow_failure:exit_codes
  • artifacts
    • artifacts:paths
    • artifacts:exclude
    • artifacts:expire_in
    • artifacts:expose_as
    • artifacts:name
    • artifacts:public
    • artifacts:access
    • artifacts:reports
    • artifacts:untracked
    • artifacts:when
  • before_script
  • cache
    • cache:paths
    • cache:key
      • cache:key:files
      • cache:key:prefix
    • cache:untracked
    • cache:unprotect
    • cache:when
    • cache:policy
    • cache:fallback_keys
  • coverage
  • dast_configuration
  • dependencies
  • environment
    • environment:name
    • environment:url
    • environment:on_stop
    • environment:action
    • environment:auto_stop_in
    • environment:kubernetes
    • environment:deployment_tier
    • 동적 환경
  • extends
  • hooks
    • hooks:pre_get_sources_script
  • identity
  • id_tokens
  • image
    • image:name
    • image:entrypoint
    • image:docker
    • image:pull_policy
  • inherit
    • inherit:default
    • inherit:variables
  • interruptible
  • needs
    • needs:artifacts
    • needs:project
    • needs:pipeline:job
    • needs:optional
    • needs:pipeline
    • needs:parallel:matrix
  • pages
    • pages:publish
    • pages:pages.path_prefix
  • parallel
    • parallel:matrix
  • release
    • release:tag_name
    • release:tag_message
    • release:name
    • release:description
    • release:ref
    • release:milestones
    • release:released_at
    • release:assets:links
  • resource_group
  • retry
    • retry:when
    • retry:exit_codes
  • rules
    • rules:if
    • rules:changes
      • rules:changes:paths
      • rules:changes:compare_to
    • rules:exists
    • rules:when
    • rules:allow_failure
    • rules:needs
    • rules:variables
    • rules:interruptible
  • script
  • 비밀
    • 비밀:보울트
    • 비밀:gcp_secret_manager
    • 비밀:azure_key_vault
    • 비밀:file
    • services:docker
    • services:pull_policy
  • stage
    • stage: .pre
    • stage: .post
  • tags
  • timeout
  • trigger
    • trigger:include
    • trigger:project
    • trigger:strategy
    • trigger:forward
  • variables
    • variables:description
    • variables:value
    • variables:options
    • variables:expand
    • when
• 사용되지 않는 키워드
  • 글로벌로 정의된 image, services, cache, before_script, after_script
  • only / except
    • only:refs / except:refs
    • only:variables / except:variables
    • only:changes / except:changes
    • only:kubernetes / except:kubernetes

CI/CD YAML 구문 참조

이 문서는 GitLab .gitlab-ci.yml 파일의 구성 옵션을 나열합니다. 이 파일은 워크플로우를 구성하는 CI/CD 작업을 정의하는 곳입니다.

• 이미 기본 CI/CD 개념에 익숙하다면, 간단한 또는 복잡한 워크플로우를 보여주는 튜토리얼에 따라 고유한 .gitlab-ci.yml 파일을 만들어보세요.
• 다양한 예제는 GitLab CI/CD 예제를 참조하세요.
• 엔터프라이즈에서 사용된 대규모 .gitlab-ci.yml 파일은 .gitlab 파일 for gitlab을 참조하세요.

.gitlab-ci.yml 파일을 편집하는 경우, CI Lint 도구를 사용하여 유효성을 검사할 수 있습니다.

이 페이지의 콘텐츠를 편집하는 경우, 키워드 문서화 지침을 따르세요.

키워드

GitLab CI/CD 워크플로우 구성에는 다음이 포함됩니다:

• 워크플로우 동작을 구성하는 전역 키워드:

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

• 헤더 키워드

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

• 작업은 작업 키워드로 구성됩니다:

  키워드	설명
  after_script	작업 이후에 실행되는 명령어 세트 재정의.
  allow_failure	작업 실패 허용. 실패한 작업이 파이프라인 실행 실패를 야기하지 않음.
  artifacts	작업 성공 시 작업에 첨부할 파일 및 디렉터리 디렉터리.
  before_script	작업 전에 실행되는 명령어 세트 재정의.
  cache	연이어 실행 사이에 캐시될 파일 디렉터리.
  coverage	특정 작업의 코드 커버리지 설정.
  dast_configuration	작업 수준에서 DAST 프로필의 구성 사용.
  dependencies	지정된 작업에 전달되는 아티팩트 제한.
  environment	작업이 배포되는 환경의 이름.
  extends	해당 작업이 상속하는 구성 항목.
  identity	ID 연동을 사용하여 타사 서비스 인증.
  image	도커 이미지 사용.
  inherit	모든 작업이 상속하는 전역 기본 선택.
  interruptible	새로운 실행에 의해 불필요해지면 작업을 취소할 수 있는지 여부 정의.
  needs	스테이지 순서보다 일찍 작업 실행.
  pages	GitLab Pages에 사용할 작업 결과 업로드.
  parallel	작업의 병렬 실행 횟수.
  release	러너가 릴리스 개체를 생성하도록 지시.
  resource_group	작업 동시성 제한.
  retry	작업 실패 시 자동 재시도할 수 있는 시점 및 횟수 정의.
  rules	작업의 선택된 특성 평가 및 결정을 위한 조건 디렉터리 및 작업 생성 여부.
  script	러너가 실행하는 셸 스크립트.
  secrets	작업에서 필요로 하는 CI/CD 비밀.
  services	도커 서비스 이미지 사용.
  stage	작업 스테이지 정의.
  tags	러너를 선택하는 데 사용되는 태그 디렉터리.
  timeout	프로젝트 수준 설정을 우선시하는 사용자 정의 작업 수준 시간 초과 정의.
  trigger	하위 파이프라인 트리거 정의.
  variables	작업 수준에서 작업 변수 정의.
  when	작업 실행 시점 정의.

전역 키워드

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

default

• id_tokens의 지원은 GitLab 16.4에서 도입되었습니다.

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

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

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

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

default의 예시:

default:
  image: ruby:3.0
  retry: 2

rspec:
  script: bundle exec rspec

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

이 예시에서:

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

추가 세부 정보:

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

include

• 문서는 11.4에서 GitLab Free로 이동되었습니다.

include를 사용하여 CI/CD 구성에서 외부 YAML 파일을 포함시킵니다. 하나의 긴 .gitlab-ci.yml 파일을 여러 파일로 분할하여 가독성을 높이거나 여러 위치에서 동일한 구성을 줄일 수 있습니다.

또한 중앙 리포지터리에 템플릿 파일을 저장한 다음 해당 템플릿을 프로젝트에 포함할 수 있습니다.

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

• .gitlab-ci.yml 파일과 Merge됩니다.
• 항상 먼저 평가한 다음 .gitlab-ci.yml 파일의 내용과 Merge되며, include 키워드의 위치에 관계없이 항상 Merge됩니다.

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

키워드 유형: 글로벌 키워드입니다.

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

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

그리고 선택적으로:

• include:inputs
• include:rules

추가 정보:

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

관련 주제:

• include와 함께 변수 사용.
• include와 함께 rules 사용.

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 확장자여야 합니다.
• 파일 경로에 와일드카드인 * 및 **를 사용할 수 있습니다.
• 특정 CI/CD 변수를 사용할 수 있습니다.

include:local의 예시:

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

다음과 같이 경로를 지정하는 간단한 구문을 사용할 수도 있습니다:

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

추가 세부 정보:

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

include:project

같은 GitLab 인스턴스의 다른 비공개 프로젝트에서 파일을 포함하려면 include:project 및 include:file을 사용합니다.

키워드 유형: 글로벌 키워드입니다.

가능한 입력:

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

include:project의 예시:

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

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

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

추가 세부 정보:

• 모든 방법으로 포함된 .gitlab-ci.yml 파일 구성이 평가됩니다. 구성은 시간에 따라 스냅샷으로 유지되며 데이터베이스에 유지됩니다. GitLab은 참조된 .gitlab-ci.yml 파일 구성의 변경을 다음 파이프라인이 시작될 때까지 반영하지 않습니다.
• 다른 비공개 프로젝트에서 YAML 파일을 포함할 때, 파이프라인을 실행하는 사용자는 두 프로젝트의 멤버이어야 하고 파이프라인을 실행할 적절한 권한이 있어야 합니다. 포함된 파일 중 하나에 대한 액세스 권한이 없는 경우 찾을 수 없음 또는 액세스 거부됨 오류가 표시될 수 있습니다.
• 다른 프로젝트의 CI/CD 구성 파일을 포함할 때 주의하십시오. CI/CD 구성 파일이 변경되면 파이프라인이나 알림이 트리거되지 않습니다. 보안적인 측면에서, 이는 제3자 의존성을 가져오는 것과 유사합니다. ref에 대한 고려 사항:
  • 가장 안정적인 옵션인 특정 SHA 해시를 사용하십시오. 원하는 커밋이 참조되도록 하기 위해 전체 40자리 SHA 해시를 사용하십시오. ref의 단축 SHA 해시를 사용하는 것은 모호할 수 있으므로 표준적인 커밋을 참조하는 것을 보장할 수 있도록 전체적인 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 템플릿:

• 모든 템플릿은 .gitlab-ci.yml과 함께 사용되도록 설계되지 않았으므로 사용하기 전에 템플릿 주석을 확인하세요.
• 특정한 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에서 Beta 기능으로 도입되었습니다.

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

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

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

include:inputs의 예시:

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

이 예시에서:

• custom_configuration.yml에 포함된 구성이 website 입력을 My website 값으로 설정하여 파이프라인에 추가됩니다.

추가 정보:

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

관련 주제:

• include을 사용할 때 입력 값 설정하기(inputs.md#set-input-values-when-using-include).

stages

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

stages를 사용하여 그룹화된 작업 단계를 정의합니다. 작업에서 stage를 사용하여 작업을 특정 단계에서 실행하도록 구성합니다.

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

• .pre
• build
• test
• deploy
• .post

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

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

만약 파이프라인에 .pre 또는 .post 단계의 작업만 포함되어 있다면, 실행되지 않습니다. 다른 단계에서 적어도 하나의 다른 작업이 있어야 합니다.

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

stages의 예시:

stages:
  - build
  - test
  - deploy

이 예시에서:

1. build에 있는 모든 작업은 병렬로 실행됩니다.
2. build에 있는 모든 작업이 성공하면, test 작업이 병렬로 실행됩니다.
3. test에 있는 모든 작업이 성공하면, deploy 작업이 병렬로 실행됩니다.
4. deploy에 있는 모든 작업이 성공하면, 파이프라인은 passed로 표시됩니다.

만약 어떠한 작업이 실패하면, 파이프라인은 failed로 표시되고 이후 단계의 작업은 시작되지 않습니다. 현재 단계의 작업은 중단되지 않고 계속 실행됩니다.

추가 정보:

• 만약 작업이 stage를 지정하지 않았다면, 작업은 test 단계에 할당됩니다.
• 단계가 정의되어 있지만 어떠한 작업도 그것을 사용하지 않는다면, 해당 단계는 파이프라인에서 보이지 않게 되며, 이는 준수 파이프라인 구성을 돕습니다:
  • 단계는 준수 구성에 정의될 수 있지만 사용되지 않는 경우 숨겨집니다.
  • 작업 정의에서 개발자가 사용하는 경우에만 정의된 단계가 보이게 됩니다.

관련 주제:

• 작업을 더 빨리 시작하고 단계 순서를 무시하려면 needs 키워드를 사용하세요.

workflow

workflow를 사용하여 파이프라인 동작을 제어하세요.

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

관련 주제:

• workflow: rules 예시
• 브랜치 파이프라인과 Merge Request 파이프라인 사이를 전환하기(workflow.md#switch-between-branch-pipelines-and-merge-request-pipelines)

workflow: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이 제거되었습니다.

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

가능한 입력값:

• conservative: 파이프라인을 취소하지만, interruptible: false를 가진 작업이 시작되지 않은 경우에만 취소됩니다. 정의되지 않았을 때 기본적으로 적용됩니다.
• interruptible: interruptible: true를 가진 작업만 취소됩니다.
• none: 어떠한 작업도 자동 취소되지 않습니다.

workflow:auto_cancel:on_new_commit의 예시:

workflow:
  auto_cancel:
    on_new_commit: interruptible

job1:
  interruptible: true
  script: sleep 60

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

이 예시에서:

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

workflow:auto_cancel:on_job_failure

• GitLab 16.10에서 auto_cancel_pipeline_on_job_failure이라는 플래그로 도입되었습니다. 기본값은 비활성화되어 있습니다.
• GitLab 16.11에서 일반적으로 사용할 수 있습니다. 피처 플래그 auto_cancel_pipeline_on_job_failure가 제거되었습니다.

workflow:auto_cancel:on_job_failure을 사용하여 어떤 작업이 실패하자마자 취소될지를 구성합니다.

가능한 입력:

• all: 한 작업이 실패하면 파이프라인 및 모든 실행 중인 작업을 즉시 취소합니다.
• none: 자동으로 아무 작업도 취소하지 않습니다.

workflow:auto_cancel:on_job_failure의 예시:

stages: [stage_a, stage_b]

workflow:
  auto_cancel:
    on_job_failure: all

job1:
  stage: stage_a
  script: sleep 60

job2:
  stage: stage_a
  script:
    - sleep 30
    - exit 1

job3:
  stage: stage_b
  script:
    - sleep 30

이 예에서 job2가 실패하면, job1이 여전히 실행 중이라면 그것은 취소되고, job3은 시작되지 않습니다.

관련 주제:

• 하향 파이프라인에서 부모 파이프라인 자동 취소

workflow:name

• GitLab 15.5에서 pipeline_name이라는 플래그로 도입되었습니다. 기본값은 비활성화되어 있습니다.
• GitLab 15.7에서 GitLab.com 및 Self-Managed에서 활성화되었습니다.
• GitLab 15.8에서 일반적으로 사용할 수 있습니다. 피처 플래그 pipeline_name이 제거되었습니다.

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

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

가능한 입력:

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

workflow:name의 예시:

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

workflow:
  name: '브랜치용 파이프라인: $CI_COMMIT_BRANCH'

파이프라인 조건에 따라 다른 파이프라인 이름을 구성한 설정:

variables:
  PROJECT1_PIPELINE_NAME: '기본 파이프라인 이름'  # 기본값은 필요하지 않습니다.

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

추가 세부 정보:

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

workflow:rules

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

규칙이 하나도 참이 되지 않으면 파이프라인이 실행되지 않습니다.

가능한 입력: 작업 수준의 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

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

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

전역 수준에서 이미 정의된 변수가 있으면, workflow 변수가 우선시되어 전역 변수를 덮어쓰고 재정의합니다.

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

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

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

workflow:rules:variables의 예시:

variables:
  DEPLOY_VARIABLE: "기본-배포"

workflow:
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      variables:
        DEPLOY_VARIABLE: "프로덕션 배포"  # 전역으로 정의된 DEPLOY_VARIABLE을 덮어씁니다.
    - if: $CI_COMMIT_REF_NAME =~ /feature/
      variables:
        IS_A_FEATURE: "true"                 # 새 변수를 정의합니다.
    - when: always                           # 그 외의 경우에 파이프라인을 실행합니다

job1:
  variables:
    DEPLOY_VARIABLE: "job1-기본-배포"
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      variables:                                   # 작업 수준에서 정의된 DEPLOY_VARIABLE을 덮어씁니다.
        DEPLOY_VARIABLE: "job1-프로덕션 배포"
    - when: on_success                             # 다른 경우에 작업을 실행합니다
  script:
    - echo "스크립트 실행: $DEPLOY_VARIABLE을(를) 인수로 사용"
    - echo "만약 $IS_A_FEATURE이(가) 존재하면 다른 스크립트 실행"

job2:
  script:
    - echo "스크립트 실행: $DEPLOY_VARIABLE을(를) 인수로 사용"
    - echo "만약 $IS_A_FEATURE이(가) 존재하면 다른 스크립트 실행"

기본 브랜치인 경우:

• job1의 DEPLOY_VARIABLE은 job1-프로덕션 배포입니다.
• job2의 DEPLOY_VARIABLE은 프로덕션 배포입니다.

feature 브랜치인 경우:

• job1의 DEPLOY_VARIABLE은 job1-기본-배포이며, IS_A_FEATURE은 true입니다.
• job2의 DEPLOY_VARIABLE은 기본-배포이고, IS_A_FEATURE은 true입니다.

다른 경우:

• job1의 DEPLOY_VARIABLE은 job1-기본-배포입니다.
• job2의 DEPLOY_VARIABLE은 기본-배포입니다.

추가 세부 정보:

• workflow:rules:variables는 기본적으로 모든 작업에서 사용 가능한 전역 변수로 설정됩니다. 기본적으로 하위 파이프라인으로 변수를 전달하는 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의 on_job_failure 옵션은 GitLab 16.10에서 auto_cancel_pipeline_on_job_failure이라는 플래그로 도입됨. 기본적으로 비활성화되어 있습니다.
• workflow:rules의 on_job_failure 옵션은 GitLab 16.11에서 일반 사용 가능한 상태로 변경됨. auto_cancel_pipeline_on_job_failure 플래그가 제거됨.

workflow:rules:auto_cancel은 workflow:auto_cancel:on_new_commit 또는 workflow:auto_cancel:on_job_failure 기능의 동작을 구성하는 데 사용됩니다.

가능한 입력:

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

workflow:rules:auto_cancel 예시:

workflow:
  auto_cancel:
    on_new_commit: interruptible
    on_job_failure: all
  rules:
    - if: $CI_COMMIT_REF_PROTECTED == 'true'
      auto_cancel:
        on_new_commit: none
        on_job_failure: none
    - when: always                  # 이외의 경우에는 파이프라인 실행
test-job1:
  script: sleep 10
  interruptible: false
test-job2:
  script: sleep 10
  interruptible: true

이 예시에서 workflow:auto_cancel:on_new_commit은 기본적으로 interruptible로 설정되고, workflow:auto_cancel:on_job_failure는 모든 작업에 대해 all로 설정됩니다. 그러나 보호된 브랜치에 대한 파이프라인이 실행되면 규칙이 기본값을 재정의합니다. 예를 들어, 보호되지 않은 브랜치에서 새 커밋이 푸시되면 test-job1은 계속 실행되고 test-job2는 취소됩니다. 보호된 브랜치에서 새 커밋이 푸시되면 test-job1과 test-job2 모두 계속 실행됩니다.

해더 키워드

일부 키워드는 YAML 구성 파일의 해더 섹션에 정의되어야 합니다. 해더는 다른 구성과 구분되고 ---로 분리되어야 합니다.

spec

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

include 키워드를 사용하여 파이프라인에 구성을 추가할 때 구성이 파이프라인 동작을 구성하는 spec 섹션을 해더에 추가하세요.

spec:inputs

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

입력을 사용하여 CI/CD 구성이 파이프라인에 포함될 때의 동작을 사용자 정의하세요.

인터폴레이션 형식인 $[[ input.input-id ]]를 사용하여 해더 섹션 외부의 값에 참조하세요. 입력은 파이프라인 생성 시 구성을 가져오지만 .gitlab-ci.yml 파일 내용과 Merge되기 전에 평가 및 보간됩니다.

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

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

spec:inputs 예시:

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

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

추가 세부 정보:

• 입력은 spec:inputs:default를 사용하여 기본 값을 설정하지 않는 한 필수입니다.
• 입력은 다른 입력 유형을 설정하기 위해 spec:inputs:type를 사용하지 않는 한 문자열을 기대합니다.
• 보간 블록 내의 문자열은 1 MB를 초과해서는 안 되며, 보간 블록 내의 문자열은 1 KB를 초과해서는 안 됩니다.

관련 주제:

• spec:inputs로 입력 매개변수 정의.

spec:inputs:default

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

spec:inputs:default를 사용하여 포함될 때 입력은 기본적으로 필수이지만 기본 값을 설정하여 선택 사항으로 만들 수 있습니다.

기본값으로 ''를 사용하여 기본 값이 없도록 설정할 수 있습니다.

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

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

spec:inputs:default 예시:

spec:
  inputs:
    website:
    user:
      default: 'test-user'
    flags:
      default: ''
---

# The pipeline configuration would follow...

이 예시에서:

• website는 필수이며 정의되어야 합니다.
• user는 선택 사항입니다. 정의되지 않으면 값은 test-user가 됩니다.
• flags는 선택 사항입니다. 정의되지 않으면 값이 없습니다.

추가 세부 정보:

• 입력이 다음 조건을 충족하지 않을 때 파이프라인은 유효성 검사 오류로 실패합니다:
  • default와 options을 동시에 사용하지만 기본 값이 디렉터리된 옵션 중 하나가 아님.
  • default와 regex를 동시에 사용하지만 기본 값이 정규식과 일치하지 않음.
  • type과 일치하지 않는 경우.(options를 사용할 때 boolean이 아닌 경우)
  • 입력이 존재하지 않는 경우에 대한 처리를 옵션 중 하나로 설정하려고 하는 경우.

spec:inputs:description

• GitLab 16.5에서 도입됨.

description을 사용하여 특정 입력에 설명을 제공할 수 있습니다. 해당 설명은 입력의 동작에 영향을 미치지 않으며 파일 사용자가 입력에 대한 이해를 돕기 위해서만 사용됩니다.

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

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

spec:inputs:description 예시:

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

# The pipeline configuration would follow...

spec:inputs:options

• GitLab 16.6에서 도입됨.

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

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

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

spec:inputs:options 예시:

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

# The pipeline configuration would follow...

이 예시에서:

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

추가 세부 정보:

• 파이프라인은 다음과 같은 경우 유효성 검사 오류로 실패합니다:
  • 입력이 options와 default을 동시에 사용하지만 기본 값이 옵션 중 하나가 아님.
  • 입력 옵션이 type과 일치하지 않는 경우.(options을 사용할 때 boolean은 아님)

spec:inputs:regex

• GitLab 16.5에서 소개됨.

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

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

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

spec:inputs:regex의 예시:

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

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

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

추가 정보:

• inputs:regex는 type이 string일 때에만 사용할 수 있으며, number나 boolean은 사용할 수 없습니다.

spec:inputs:type

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

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

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

• 입력의 배열을 받기 위해 array.
• 문자열 입력을 받기 위해 string (기본값).
• 숫자 입력만 받기 위해 number.
• true 또는 false 입력만 받기 위해 boolean.

spec:inputs:type의 예시:

spec:
  inputs:
    job_name:
    website:
      type: string
    port:
      type: number
    available:
      type: boolean
    array_input:
      type: array  
---

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

작업 키워드

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

after_script

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

Keyword type: 작업 키워드. 작업 내에서만 사용할 수 있습니다. 또는 default 섹션에서 사용할 수 있습니다.

가능한 입력: 단일 라인 명령어, 여러 줄에 걸쳐 분할된 긴 명령어, YAML 앵커를 포함한 배열.

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

after_script의 예시:

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

추가 정보:

after_script에 지정된 스크립트는 새로운 셸에서 실행되므로 다음과 같은 특성을 가집니다:

• 현재 작업 디렉터리가 기본값으로 설정됩니다( 러너(runner)가 Git 요청을 처리하는 방식을 정의하는 변수에 따라).
• before_script 또는 script 스크립트에서 수행된 변경 내용에 액세스할 수 없습니다. 이는 script 스크립트에서 내보낸 명령 별칭 및 변수, before_script 또는 script 스크립트에서 설치된 소프트웨어와 같은 작업 디렉터리 외부 변경 사항을 포함합니다.
• 별도의 타임아웃을 가집니다. GitLab Runner 16.4 이상에서는 기본값이 5분이며, RUNNER_AFTER_SCRIPT_TIMEOUT 변수로 구성할 수 있습니다. GitLab 16.3 이하에서는 타임아웃이 하드 코딩되어 5분입니다.
• 작업의 종료 코드에 영향을 주지 않습니다. script 섹션이 성공하고 after_script가 타임아웃되거나 실패하면 작업은 코드 0 (작업 성공)으로 종료됩니다.

작업이 타임아웃되면 after_script 명령어가 실행되지 않습니다. 타임아웃된 작업에 대한 after_script 명령어 실행을 추가 지원하도록하는 이슈가 있습니다.

관련 주제:

• default와 함께 after_script 사용하여 모든 작업 뒤에 실행할 기본 명령어 배열을 정의합니다.
• 0이 아닌 종료 코드 무시.
• after_script에 색상 코드 사용하여 작업 로그를 쉽게 검토합니다.
• 사용자 정의 접기 가능 섹션 생성하여 작업 로그 출력을 단순화합니다.

allow_failure

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

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

작업이 실패할 수 있도록 허용되면 (allow_failure: true), 주황색 경고 ()가 표시되며, 작업이 실패한 것으로 표시됩니다. 그러나 파이프라인은 성공적이고 해당 커밋은 경고 없이 통과한 것으로 표시됩니다.

이와 유사한 경고는 다음 경우에도 표시됩니다:

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

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

• 매뉴얼 작업에 대해 true.
• [rules 내부에서 when: manual을 사용하는 작업에 대해 false.
• 모든 다른 경우에 대해 false.

Keyword type: 작업 키워드. 작업 내에서만 사용할 수 있습니다.

가능한 입력:

• true 또는 false.

allow_failure의 예시:

job1:
  stage: test
  script:
    - execute_script_1

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

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

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

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

추가 정보:

• allow_failure은 rules의 하위키로 사용할 수 있습니다.
• allow_failure: true로 설정하면 작업은 항상 성공한 것으로 간주되며, 이 작업이 실패하는 경우 나중에 when: on_failure로 시작되는 후속 작업은 시작되지 않습니다.
• 매뉴얼 작업에 allow_failure: false을 사용하여 블로킹 매뉴얼 작업을 만들 수 있습니다. 블로킹된 파이프라인은 매뉴얼 작업이 시작되어 성공적으로 완료될 때까지 나중 단계의 어떤 작업도 실행되지 않습니다.

allow_failure:exit_codes

allow_failure:exit_codes를 사용하여 작업이 허용되는 시점을 제어합니다. 작업은 디렉터리된 종료 코드 중 하나에 대해 allow_failure: true이고 나머지 종료 코드에 대해 allow_failure이 false입니다.

Keyword type: 작업 키워드. 작업 내에서만 사용할 수 있습니다.

가능한 입력:

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

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

작업 artifact을 저장할 파일을 지정하는 데 artifacts를 사용합니다. 작업 artifact은 작업이 성공, 실패 또는 항상될 때 첨부되는 파일 및 디렉터리 디렉터리입니다.

작업이 완료된 후 artifact은 GitLab으로 전송됩니다. 이들은 다음과 같은 경우에 GitLab UI에서 다운로드할 수 있습니다. - 최대 artifact 크기보다 작을 때 (gitlab-cicd 참조).

기본적으로 후속 단계의 작업은 이전 단계에서 생성된 모든 artifact을 자동으로 다운로드합니다. 직접적인 제어를 원한다면 작업에서 dependencies를 사용할 수 있습니다.

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

기본적으로 작업 artifact은 성공한 작업에 대해서만 수집되며, artifact는 caches 이후에 복원됩니다.

artifact에 대해 자세히 알아보기.

artifacts:paths

경로는 프로젝트 디렉터리($CI_PROJECT_DIR)를 기준으로 하며, 직접적으로 외부 링크할 수 없습니다.

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

가능한 입력:

• 프로젝트 디렉터리를 기준으로 한 파일 경로의 배열.
• glob 패턴을 사용하는 와일드카드로:
  • GitLab Runner 13.0 and later에서는 doublestar.Glob.
  • GitLab Runner 12.10 및 이전에는 filepath.Match.

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

artifacts:paths의 예시:

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

이 예시는 .config와 binaries 디렉터리의 모든 파일을 포함하는 artifact을 생성합니다.

추가 정보:

• artifacts:name과 함께 사용되지 않으면 artifact 파일은 artifacts로 명명되며, 다운로드될 때 artifacts.zip가 됩니다.

관련 주제:

• 특정 작업이 가져온 artifact을 제한하려면 dependencies를 참조하세요.
• 작업 artifact 생성.

artifacts:exclude

artifacts:exclude를 사용하여 artifact 아카이브에 파일을 추가하지 않도록 합니다.

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

가능한 입력:

• 프로젝트 디렉터리를 기준으로 한 파일 경로의 배열.
• glob이나 doublestar.PathMatch 패턴.

artifacts:exclude의 예시:

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

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

추가 정보:

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

관련 주제:

• 작업 artifact에서 파일 제외하기.

artifacts:expire_in

작업 artifact이 만료되어 삭제되기 전에 저장되는 기간을 지정하려면 expire_in을 사용합니다. expire_in 설정은 다음에 영향을 주지 않습니다:

• 특정 작업의 artifact은 만료되지 않습니다. 최신 작업 artifact은 프로젝트 수준이나 인스턴스 수준에서 최신 성공한 작업의 artifact 유지가 비활성화되지 않는 한.

만료되면 artifact은 기본적으로 시간마다(크론 작업을 사용) 삭제되며 더 이상 접근할 수 없습니다.

키워드 유형: 작업 키워드. 작업 내에서만 사용하거나, 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

추가 정보:

• 만료 시간은 artifact이 GitLab에 업로드되고 저장된 시점부터 시작됩니다. 만료 시간이 정의되지 않은 경우, 인스턴스 기본 설정으로 기본 설정됩니다.
• 만료 날짜를 무시하고 artifact을 자동으로 삭제되지 않도록 하려면:
  • 작업 페이지에서 유지하기를 선택합니다.
  • expire_in 값을 never로 설정합니다.
• 만료 시간이 너무 짧으면, 긴 Pipeline의 후속 단계의 작업이 이전 작업에서 만료된 artifact을 가져오려고 할 수 있습니다. Artifact이 만료되면 시도가 실패하여, 만료된 artifact을 가져오려고 시도하는 작업이 필요한 artifact을 검색하지 못함 에러와 함께 실패합니다. 만료시간을 길게 설정하거나, 나중에 작업에서 dependencies를 사용하여, 만료된 artifact을 검색하지 않도록합니다.

artifacts:expose_as

artifacts:expose_as 키워드를 사용하여 Merge Request UI에서 작업 artifact을 노출합니다.

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

가능한 입력:

• Merge Request UI에 표시할 artifact 다운로드 링크의 이름. artifacts:paths와 결합되어야합니다.

artifacts:expose_as의 예시:

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

추가 정보:

• 만약 artifacts:expose_as 값을 사용하려면, 다음과 같은 상황에서 UI에 표시되지 않는다.
  • CI/CD 변수를 사용합니다.
  • 디렉터리를 정의하려고 하지만 /로 끝나지 않습니다. 예를 들어, directory/은 artifacts:expose_as와 함께 작동하지만, directory는 작동하지 않습니다.
  • ./로 시작합니다. 예를 들어, file은 artifacts:expose_as에서 작동하지만, ./file은 작동하지 않습니다.
• Merge Request당 최대 10개의 작업 artifact을 노출할 수 있습니다.
• Glob 패턴은 지원되지 않습니다.
• 디렉터리가 지정되고 디렉터리 내에 둘 이상의 파일이 있는 경우, 링크는 작업 artifact 브라우저로 이동합니다.
• GitLab Pages가 활성화된 경우, GitLab은 다음과 같은 확장자가 있는 단일 파일에 artifact을 자동으로 변환합니다.
  • .html 또는 .htm
  • .txt
  • .json
  • .xml
  • .log

관련 주제:

• Merge Request UI에서 작업 artifact 노출.

artifacts:name

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

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

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

가능한 입력값:

• artifacts 아카이브의 이름. CI/CD 변수 지원됨. artifacts:paths와 결합해야 합니다.

artifacts:name의 예:

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

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’으로 생성된 artifacts는 이 업데이트 이후 비공개 보장되지 않음.
• GitLab 16.7에서 일반적으로 사용 가능함. ‘non_public_artifacts’ 플래그가 제거됨.

artifacts:public을 사용하여 Job artifacts가 공개적으로 사용 가능한지를 결정합니다.

artifacts:public이 true인 경우(기본값), 공개적인 파이프라인에서의 artifacts는 익명, 게스트 및 기록 사용자에 의해 다운로드할 수 있습니다.

공개 파이프라인의 artifacts에 대해 읽기 액세스를 거부하려면, artifacts:public을 false로 설정하세요.

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

가능한 입력값:

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

artifacts:public의 예:

job:
  artifacts:
    public: false

artifacts:access

• GitLab 16.11에서 도입됨.

artifacts:access를 사용하여 job artifacts에 액세스할 수 있는 사용자를 결정합니다.

동일한 Job에서 artifacts:public와 artifacts:access를 동시에 사용할 수 없습니다.

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

가능한 입력값:

• all (기본값): 공개 파이프라인의 Job에서 생성된 artifacts는 익명, 게스트 및 기록 사용자를 포함한 누구나 다운로드할 수 있습니다.
• developer: Job의 artifacts는 ‘Developer’ 역할 이상의 사용자만 다운로드할 수 있습니다.
• none: Job의 artifacts는 누구에게도 다운로드할 수 없습니다.

artifacts:access의 예:

job:
  artifacts:
    access: 'developer'

추가 세부 정보:

• artifacts:access는 모든 artifacts:reports에 영향을 미칩니다. 따라서 보고서용 artifacts에 대한 액세스도 제한할 수 있습니다.

artifacts:reports

Job에 포함된 템플릿에서 생성된 artifacts를 수집하기 위해 artifacts:reports를 사용하세요.

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

가능한 입력값:

• 사용 가능한 artifacts 보고서 유형 디렉터리 참조.

artifacts:reports의 예:

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

추가 세부 정보:

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

artifacts:untracked

artifacts:untracked를 사용하여 artifacts:paths에서 정의된 경로와 함께 Git에서 추적되지 않는 모든 파일을 artifacts로 추가하세요. artifacts:untracked는 리포지터리의 .gitignore 구성을 무시하므로 .gitignore에 일치하는 artifacts가 포함됩니다.

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

가능한 입력값:

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

artifacts:untracked의 예:

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

job:
  artifacts:
    untracked: true

관련 주제:

• 추적되지 않은 파일을 artifacts에 추가.

artifacts:when

artifacts:when을 사용하여 작업이 실패하거나 실패에도 불구하고 artifacts를 업로드하세요.

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

가능한 입력값:

• on_success (기본값): 작업이 성공했을 때만 artifacts를 업로드합니다.
• on_failure: 작업이 실패했을 때만 artifacts를 업로드합니다.
• always: 항상 artifacts를 업로드합니다(작업이 시간 초과될 때를 제외). 예를 들어, 실패하는 테스트를 해결하기 위해 artifacts를 업로드해야 하는 경우.

artifacts:when의 예:

job:
  artifacts:
    when: on_failure

추가 세부 정보:

• artifacts:reports를 위해 생성된 artifacts는 작업 결과(성공 또는 실패)와 상관없이 항상 업로드됩니다. artifacts:when은 이러한 동작을 바꾸지 않습니다.

before_script

before_script을 사용하여 각 job의 script 명령어 실행 전에 실행되어야 하는 명령어 배열을 정의하세요. 이때 artifacts가 복원됩니다.

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

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

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

CI/CD 변수 지원됨.

before_script의 예:

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

추가 세부 정보:

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

관련 주제:

• default와 함께 사용하여 before_script 정의.
• 0이 아닌 종료 코드 무시.
• before_script과 함께 색상 코드 사용하여 작업 로그를 쉽게 검토하세요.
• 사용자 정의로 만든 접기 가능한 섹션들을 생성하여 작업 로그 출력을 간소화하세요.

cache

• GitLab 15.0에 소개된 캐시는 보호된 브랜치와 비보호된 브랜치 사이에서 공유되지 않습니다.

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

캐시:

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

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

• default로 정의된 기본 캐시.
• include로 추가된 작업의 구성을 재정의합니다.

다양한 cache 사용 사례는 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

cache:key:files 키워드를 사용하여 특정 파일 또는 두 파일이 변경될 때마다 새 키를 생성합니다. cache:key:files를 사용하면 일부 캐시를 재사용하고, 나중에 실행되는 파이프라인을 가속화하여 적게 다시 빌드할 수 있습니다.

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

가능한 입력값:

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

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

cache:key:files 예시:

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

이 예시에서는 Ruby 및 Node.js 의존성에 대한 캐시를 생성합니다. 캐시는 Gemfile.lock 및 package.json 파일의 현재 버전과 관련됩니다. 이 파일 중 하나가 변경되면 새 캐시 키가 계산되고 새 캐시가 생성됩니다. cache:key:files로 동일한 Gemfile.lock 및 package.json을 사용하는 후속 작업 실행은 새 캐시를 다시 빌드하는 대신 새 캐시를 사용합니다.

추가 상세정보:

• 캐시 key는 각 디렉터리된 파일에 대해 변경된 가장 최근의 커밋에서 계산된 SHA입니다. 어떤 커밋에서도 파일이 변경되지 않은 경우, 폴백 키는 default입니다.

cache:key:prefix

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

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

가능한 입력값:

• 문자열
• 미리 정의된 변수
• 두 가지를 결합한 것.

cache:key:prefix 예시:

rspec:
  script:
    - echo "이 rspec 작업은 캐시를 사용합니다."
  cache:
    key:
      files:
        - Gemfile.lock
      prefix: $CI_JOB_NAME
    paths:
      - vendor/ruby

예를 들어, $CI_JOB_NAME 접두사를 추가하면 키는 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로 체크아웃에 추가되지 않은 파일이 생성될 가능성이 있지만 추가되지 않은 파일입니다.

추적되지 않은 파일을 캐시하면 작업이 의도치 않게 큰 캐시를 만들 수 있습니다, 특히 작업이 다음을 다운로드할 때:

• 보통 추적되지 않은 의존성, 예를 들어 젬이나 노드 모듈.
• 다른 작업에서 추출된 artifacts. 추출된 파일은 기본적으로 추적되지 않습니다.

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

가능한 입력값:

• true 또는 false (기본값).

cache:untracked 예시:

rspec:
  script: test
  cache:
    untracked: true

추가 상세정보:

• cache:untracked를 cache:paths와 결합하여 리포지터리의 모든 추적되지 않은 파일뿐만 아니라 구성된 경로의 모든 파일을 캐시할 수 있습니다. cache:paths를 사용하여 추적되지 않을 수도 있는 특정 파일 또는 작업 디렉터리 외부 파일을 캐시하고 cache: untracked를 사용하여 리포지터리의 모든 추적되지 않은 파일을 캐시합니다. 예:

  rspec:
    script: test
    cache:
      untracked: true
      paths:
        - binaries/
  

  이 예에서 작업은 리포지터리의 모든 추적되지 않은 파일과 binaries/에 있는 모든 파일을 캐시합니다. binaries/에 추적되지 않은 파일이 있는 경우 두 경우 모두 해당됩니다.

cache:unprotect

• 소개된 GitLab 15.8에서 추가되었습니다.

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

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

가능한 입력값:

• true 또는 false (기본값).

cache:unprotect 예시:

rspec:
  script: test
  cache:
    unprotect: true

cache:when

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

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

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

가능한 입력값:

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

cache:when 예시:

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

이 예시는 작업이 실패하거나 성공하더라도 캐시를 저장합니다.

cache:policy

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

작업을 시작할 때 캐시를 다운로드만 하고, 작업을 끝낼 때는 변경 사항을 캐시에 업로드하지 않으려면 cache:policy:pull을 사용하세요.

작업을 끝낼 때 캐시를 업로드만 하고, 작업을 시작할 때는 캐시를 다운로드하지 않으려면 cache:policy:push를 사용하세요.

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

키워드 유형: Job 키워드. 작업의 일부로만 사용하거나 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+)?/'

이 예시에서:

1. GitLab은 작업 로그에서 정규 표현식과 일치하는지 확인합니다. Code coverage: 67.89% of lines covered와 같은 줄이 일치합니다.
2. 그런 다음 GitLab은 일치하는 단편에서 \d+(?:\.\d+)?와 일치하는지 확인합니다. 위의 일치하는 줄은 67.89의 코드 커버리지를 제공합니다.

추가 세부 정보:

• 코드 커버리지에서 구문 분석 예제를 찾을 수 있습니다.
• 작업 출력에 일치하는 줄이 여러 개 있는 경우 마지막 줄이 사용됩니다(역순 검색의 첫 번째 결과).
• 작업 출력에서 여러 일치 항목이 있는 경우 가장 마지막 일치 항목이 코드 커버리지 숫자를 검색합니다.
• 일치하는 단편에서 여러 코드 커버리지 숫자가 발견되면 첫 번째 숫자가 사용됩니다.
• 선행하는 0은 제거됩니다.
• 하위 파이프라인의 코드 커버리지 출력이 기록되거나 표시되지 않습니다. 자세한 내용은 관련 이슈를 확인하세요.

dast_configuration

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"

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

추가 세부 정보:

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

관련 주제:

• 사이트 프로필.
• 스캐너 프로필.

dependencies

dependencies 키워드를 사용하여 artifacts를 가져올 특정 작업 디렉터리을 정의합니다. 지정된 작업은 모두 이전 단계에 있어야 합니다. 아무런 artifacts도 다운로드하지 않도록 작업을 설정할 수도 있습니다.

dependencies가 작업에서 정의되지 않으면 이전 단계의 모든 작업이 종속적으로 간주되며 작업은 해당 작업에서 모든 artifacts를 가져옵니다.

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

가능한 입력값:

• 가져올 작업명
• 빈 배열 ([]), 작업이 어떤 artifacts도 다운로드하지 않도록 구성하는 경우

dependencies의 예시:

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

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

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

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

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

이 예시에서 두 작업인 build osx와 build linux에는 artifacts가 있습니다. test osx가 실행될 때 build osx의 artifacts가 다운로드되어 빌드의 문맥에서 추출됩니다. test linux의 경우도 build linux의 artifacts가 마찬가지로 처리됩니다.

stage 우선 순위 때문에 deploy 작업은 모든 이전 작업의 artifacts를 다운로드합니다.

추가적인 세부 정보:

• 작업 상태는 중요하지 않습니다. 작업이 실패하거나 트리거되지 않은 매뉴얼 작업이더라도 오류가 발생하지 않습니다.
• 종속적인 작업의 artifacts가 만료되거나 삭제된 경우 작업이 실패합니다.
• 동일 단계에서 작업의 artifacts를 가져오려면 needs:artifacts를 사용해야 합니다. dependencies와 needs를 동일 작업에서 결합해서는 안 됩니다.

environment

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

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

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

• -, _, /, $, {, } 및 알파벳, 숫자, 공백으로 이루어진 일반 텍스트
• .gitlab-ci.yml 파일에서 정의된 사전 정의, 프로젝트, 그룹, 인스턴스 또는 변수를 포함하는 CI/CD 변수. script 섹션에서 정의된 변수는 사용할 수 없습니다.

environment의 예시:

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

추가적인 세부 정보:

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

environment:name

환경에 이름을 지정합니다.

일반적인 환경명은 qa, staging, production 등이지만 원하는 이름을 사용할 수 있습니다.

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

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

• -, _, /, $, {, } 및 알파벳, 숫자, 공백으로 이루어진 일반 텍스트
• CI/CD 변수로, 사전 정의, 프로젝트, 그룹, 인스턴스 또는 .gitlab-ci.yml 파일에서 정의된 변수를 포함합니다. script 섹션에서 정의된 변수는 사용할 수 없습니다.

environment:name의 예시:

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

environment:url

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

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

가능한 입력값: 다음 중 하나의 형식으로 작성된 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

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

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

추가적인 세부 정보:

• 자세한 내용 및 예시는 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

• GitLab 15.4에서 소개된 CI/CD 변수 지원입니다.

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

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

가능한 입력값: 일반 언어로 작성된 시간 기간입니다. 예를 들어 다음과 같습니다:

• 168 hours
• 7 days
• one week
• never

CI/CD 변수를 사용할 수 있습니다. 위치.

environment:auto_stop_in의 예시:

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

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

관련 주제:

• 환경 자동 중지 문서

environment:kubernetes

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

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

environment:kubernetes의 예시:

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

이 구성은 deploy Job을 설정하여 production 환경으로 production Kubernetes 네임스페이스를 사용하여 배포하도록 합니다.

추가 세부 정보:

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

관련 주제:

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

environment:deployment_tier

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

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

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

• production
• staging
• testing
• development
• other

environment:deployment_tier의 예시:

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

추가 세부 정보:

• 이 Job 정의에서 생성된 환경은이 값에 기반하여 티어가 할당됩니다.
• 나중에 이 값이 추가되더라도 기존 환경의 티어는 업데이트되지 않습니다. 기존 환경은 환경 API를 통해 티어를 업데이트해야 합니다.

관련 주제:

• 환경의 배포 티어.

동적 환경

CI/CD 변수를 사용하여 동적으로 환경의 이름을 지정하세요.

예를 들어:

deploy as review app:
  stage: deploy
  script: make deploy
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    url: https://$CI_ENVIRONMENT_SLUG.example.com/

deploy as review app Job은 동적으로 review/$CI_COMMIT_REF_SLUG 환경을 생성하는 배포로 표시됩니다. $CI_COMMIT_REF_SLUG는 러너에 의해 설정된 CI/CD 변수입니다. $CI_ENVIRONMENT_SLUG 변수는 환경 이름을 기반으로하지만 URL에 포함하기에 적합합니다. deploy as review app Job이 pow라는 브랜치에서 실행되면이 환경은 https://review-pow.example.com/과 같은 URL로 액세스 할 수 있습니다.

일반적인 사용 사례는 동적 환경을 브랜치에 대한 리뷰 앱으로 생성하고 사용하는 것입니다. 리뷰 앱을 사용하는 예시를 여기에서 볼 수 있습니다.

extends

extends를 사용하여 구성 섹션을 재사용합니다. 이는 YAML 앵커의 대안이며 약간 더 유연하고 가독성이 좋습니다.

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

가능한 입력:

• 파이프라인에서 다른 Job의 이름.
• 파이프라인에서 다른 Job의 이름 디렉터리 (배열).

extends의 예시:

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

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

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

• 키를 기준으로 역Merge을 수행합니다.
• .tests 내용을 rspec Job에 Merge합니다.
• 키의 값을 Merge하지 않습니다.

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

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

추가 세부 정보:

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

관련 주제:

• 구성 섹션 재사용하기.
• 포함된 구성 파일에서 구성 재사용하기.

hooks

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

hooks를 사용하여 특정 Job 실행 단계에서 러너에서 명령 디렉터리을 지정합니다. 이는 Git 리포지터리를 검색하기 전과 같은 특정 Job 실행 단계에서 러너에서 명령 디렉터리을 지정합니다.

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

가능한 입력:

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

hooks:pre_get_sources_script

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

hooks:pre_get_sources_script를 사용하여 Git 리포지터리 및 모든 서브모듈을 복제하기 전에 러너에서 실행할 명령 디렉터리을 지정합니다. 이를 사용하여 예를 들면:

• Git 구성을 조정합니다.
• 추적 변수를 내보냅니다.

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

• 단일 라인 명령.
• 여러 줄에 걸쳐 분할된 긴 명령.
• YAML 앵커.

CI/CD 변수 지원됨.

hooks:pre_get_sources_script의 예시:

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

관련 주제:

• GitLab 러너 구성

identity

• GitLab 16.9에 google_cloud_support_feature_flag라는 플래그와 함께 도입되었습니다. 이 기능은 베타 단계에 있습니다.

플래그: GitLab.com에서 이 기능은 일부 사용자를 대상으로 사용 가능합니다. GitLab Dedicated에서는 이 기능을 사용할 수 없습니다.

서드 파티 서비스에 ID 페더레이션을 사용하여 인증하는 데 identity를 사용하세요.

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

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

• google_cloud: Google Cloud. Google Cloud IAM 통합과 구성해야 합니다.

identity의 예시:

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

관련 주제:

• Workload Identity Federation.
• Google Cloud IAM 통합.

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 섹션의 일부로만 사용할 수 있습니다.

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

• <이미지-이름> (latest 태그와 함께 <이미지-이름> 사용과 동일)
• <이미지-이름>:<태그>
• <이미지-이름>@<다이제스트>

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 단독으로 사용하는 것과 유사합니다.

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

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

• <이미지-이름> (latest 태그와 함께 <이미지-이름> 사용과 동일)
• <이미지-이름>:<태그>
• <이미지-이름>@<다이제스트>

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

image:name 예시:

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

관련 주제:

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

image:entrypoint

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

도커 컨테이너가 생성될 때, entrypoint는 도커 --entrypoint 옵션으로 변환됩니다. 구문은 각 쉘 토큰이 배열의 별도 문자열임과 유사한 Docker 파일 ENTRYPOINT 지시문입니다.

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

가능한 입력:

• 문자열.

image:entrypoint 예시:

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

관련 주제:

• 이미지의 엔트리 포인트 덮어쓰기.

image:docker

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

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

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

가능한 입력:

Docker 실행기에 대한 옵션 해시를 사용할 수 있습니다:

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

image:docker 예시:

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

추가 세부 정보:

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

image:pull_policy

• GitLab 15.1에서 플래그 ci_docker_image_pull_policy와 함께 소개. 기본적으로 비활성화됩니다.
• GitLab 15.2에서 GitLab.com 및 Self-Managed에서 활성화되었습니다.
• GitLab 15.4에서 일반적으로 사용 가능합니다. 플래그 ci_docker_image_pull_policy 삭제됨.
• GitLab Runner 15.1 이상이 필요합니다.

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

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

가능한 입력:

• 단일 풀(policy) 또는 여러 풀(policy)을 배열로 사용할 수 있습니다. always, if-not-present, 또는 never일 수 있습니다.

image:pull_policy 예시:

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

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

추가 세부 정보:

• 러너가 정의된 pull policy를 지원하지 않는 경우 다음과 유사한 오류로 작업이 실패합니다: ERROR: Job failed (system failure): the configured PullPolicies ([always]) are not allowed by AllowedPullPolicies ([never]).

관련 주제:

• Docker 컨테이너에서 CI/CD 작업 실행.
• 러너가 이미지를 가져오는 방법 구성.
• 여러 풀(policy)를 설정.

inherit

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

inherit:default

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

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

가능한 입력값:

• true (기본값) 또는 false로 모든 기본 키워드의 상속을 활성화 또는 비활성화합니다.
• 상속할 특정 기본 키워드의 디렉터리.

inherit:default의 예시:

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

job1:
  script: echo "이 작업은 어떠한 기본 키워드도 상속받지 않습니다."
  inherit:
    default: false

job2:
  script: echo "이 작업은 'interruptible'을 상속받지 않고 'retry' 및 'image'만 상속받습니다."
  inherit:
    default:
      - retry
      - image

추가 정보:

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

inherit:variables

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

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

가능한 입력값:

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

inherit:variables의 예시:

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

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

job2:
  script: echo "이 작업은 'VARIABLE3'를 상속받지 않고 'VARIABLE1' 및 'VARIABLE2' 만 상속받습니다."
  inherit:
    variables:
      - VARIABLE1
      - VARIABLE2

추가 정보:

• 하나의 줄에 상속할 전역 변수를 나열할 수도 있습니다: variables: [VARIABLE1, VARIABLE2]

interruptible

• GitLab 16.8에서 도입된 trigger 작업 지원.

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

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

가능한 입력값:

• true 또는 false (기본값).

interruptible의 예시:

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

stages:
  - stage1
  - stage2
  - stage3

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

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

step-3:
  stage: stage3
  script:
    - echo "step-2가 취소될 수 없기 때문에, 이 단계 역시 취소될 수 없습니다."
  interruptible: true

이 예시에서 새 파이프라인은 다음과 같은 작동을 합니다:

• step-1이 실행 중이거나 보류 중인 경우 새 파이프라인은 취소됨.
• step-2가 시작된 후에는 취소되지 않음.

auto_cancel:on_new_commit:interruptible 설정을 사용한 interruptible의 예시:

workflow:
  auto_cancel:
    on_new_commit: interruptible

stages:
  - stage1
  - stage2
  - stage3

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

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

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

이 예시에서 새 파이프라인은 실행 중인 step-1 및 step-3이 있으면 그 작업들을 취소함.

추가 정보:

• 작업이 시작된 후에 취소될 수 있는 경우에만 interruptible: true를 설정하세요. 예를 들어 빌드 작업과 같은 작업에는 보통 취소되도록 설정되지 않아야 합니다.
• 기본 동작 또는 workflow:auto_cancel:on_new_commit: conservative를 사용하는 경우:
  • 아직 시작되지 않은 작업은 작업의 구성 여부에 관계없이 항상 interruptible: true로 간주됨. 작업이 시작된 후에는 interruptible 설정이 고려됨.
  • 실행 중인 파이프라인은 모든 실행 중인 작업이 interruptible: true로 구성되어 있거나 interruptible: false로 구성된 작업이 언제든지 시작되지 않은 경우에만 취소됨. interruptible: false로 구성된 작업이 시작된 후에는 전체 파이프라인은 더 이상 취소 가능하게 간주되지 않음.
  • 파이프라인이 다운스트림 파이프라인을 트리거했지만, 다운스트림 파이프라인에 interruptible: false로 구성된 작업이 시작되지 않은 경우, 다운스트림 파이프라인은 취소됨.
• 파이프라인의 첫 번째 단계에 interruptible: false으로 선택적 매뉴얼적 작업을 추가하여 사용자가 파이프라인이 자동으로 취소되는 것을 방지할 수 있음. 사용자가 작업을 시작한 후에는 자동 취소 중복 파이프라인 기능에 의해 파이프라인을 취소할 수 없음.
• 트리거 작업과 함께 interruptible를 사용할 때:
  • 트리거된 다운스트림 파이프라인은 트리거 작업의 interruptible 구성에 영향을 받지 않음.
  • workflow:auto_cancel를 conservative로 설정하는 경우 트리거 작업의 interruptible 구성이 영향을 미치지 않음.
  • workflow:auto_cancel를 interruptible로 설정하는 경우 interruptible: true로 구성된 트리거 작업을 자동으로 취소할 수 있음.

needs

needs를 사용하여 작업을 순서에 구애받지 않도록 실행하세요. needs를 사용하는 작업 간의 관계는 유향 비순환 그래프로 시각화할 수 있습니다.

needs를 사용하여 일부 작업을 다른 작업이 완료될 때까지 대기하지 않고 실행하고 몇몇 작업을 상호 동시에 실행할 수 있습니다.

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

가능한 입력값:

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

needs의 예시:

linux:build:
  stage: build
  script: echo "Linux 빌드 중..."

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

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

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

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

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

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

• 린터: lint 작업은 (needs: []) 때문에 build 단계가 완료될 때까지 대기하지 않고 즉시 실행됩니다.
• 리눅스 경로: linux:rspec 작업은 linux:build 작업이 완료된 후에 mac:build 작업을 기다리지 않고 바로 실행됩니다.
• macOS 경로: mac:rspec 작업은 mac:build 작업이 완료된 후에 linux:build 작업을 기다리지 않고 바로 실행됩니다.
• production 작업은 모든 이전 작업이 종료되면(lint, linux:build, linux:rspec, mac:build, mac:rspec) 즉시 실행됩니다.

추가 정보:

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

needs:artifacts

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

needs를 사용하는 작업에서 artifacts를 다운로드하는 시기를 제어하려면 artifacts: true (기본값) 또는 artifacts: false를 사용하십시오.

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

가능한 입력값:

• true (기본값) 또는 false.

needs:artifacts의 예:

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

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

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

이 예에서:

• test-job1 작업은 build_job1 artifacts를 다운로드합니다.
• test-job2 작업은 build_job2 artifacts를 다운로드하지 않습니다.
• test-job3 작업은 artifacts가 세 작업 모두에 대해 true 또는 기본값 true이기 때문에 모든 세 build_jobs의 artifacts를 다운로드합니다.

추가 세부 정보:

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

needs:project

needs:project를 사용하여 다른 파이프라인의 최대 다섯 개 작업에서 artifacts를 다운로드합니다. artifacts는 지정된 참조(ref)의 최신 성공한 지정된 작업에서 다운로드됩니다. 여러 작업을 지정하려면 needs 키워드 아래에 각각을 별도의 배열 항목으로 추가하십시오.

참조로 파이프라인이 실행 중인 경우, needs:project가 지정된 작업의 최신 성공 실행에서 artifacts를 다운로드합니다.

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

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

가능한 입력값:

• needs:project: 네임스페이스와 그룹을 포함한 완전한 프로젝트 경로.
• job: artifacts를 다운로드할 작업.
• ref: artifacts를 다운로드할 참조(ref).
• artifacts: artifacts를 다운로드하려면 반드시 true여야 합니다.

needs:project의 예:

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

이 예에서 build_job은 group/project-name 및 group/project-name-2 프로젝트의 main 브랜치에 있는 가장 최근의 성공한 build-1 및 build-2 작업에서 artifacts를 다운로드합니다.

needs:project에서 CI/CD variables을 사용할 수 있습니다. 예시:

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

추가 세부 정보:

• 현재 프로젝트에서 다른 파이프라인에서 artifacts를 다운로드하려면 project를 현재 프로젝트와 동일하게 설정하되, 현재 파이프라인과 다른 참조(ref)를 사용하십시오. 동일한 ref에서 동시에 실행되는 파이프라인은 artifacts를 덮어쓸 수 있습니다.
• 파이프라인을 실행하는 사용자는 그룹 또는 프로젝트에 대해 적어도 Reporter 역할을 가지거나, 그룹/프로젝트가 공개 가시성을 가지고 있어야 합니다.
• needs:project를 trigger와 함께 동일한 작업에서 사용할 수 없습니다.
• 다른 파이프라인에서 artifacts를 다운로드하려면 needs:project를 사용할 때, 해당 작업이 완료될 필요가 없습니다. 유향 비순환 그래프 동작은 현재 파이프라인의 작업으로 제한됩니다. 다른 파이프라인의 필요한 작업이 해당 작업을 다운로드하려고 할 때 반드시 해당 작업이 완료되었는지 확인하십시오.
• parallel에서 실행되는 작업에서는 작업을 다운로드할 수 없습니다.
• project, job, ref에서 CI/CD variables을 지원합니다.

관련 주제:

• 상위-하위 파이프라인 사이에서 artifacts를 다운로드하려면 needs:pipeline:job을 사용합니다.

needs:pipeline:job

하위 파이프라인은 상위 파이프라인이나 동일한 상위-하위 파이프라인 계층 구조 내의 다른 하위 파이프라인에서 작업에서 artifacts를 다운로드할 수 있습니다.

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

가능한 입력값:

• needs:pipeline: 파이프라인 ID. 반드시 동일한 상위-하위 파이프라인 계층 구조 내에 있는 파이프라인이어야 합니다.
• job: artifacts를 다운로드할 작업.

needs:pipeline:job의 예:

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

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

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

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

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

추가 세부 정보:

• pipeline 속성은 현재 파이프라인 ID($CI_PIPELINE_ID)를 허용하지 않습니다. 현재 파이프라인에서 작업의 artifacts를 다운로드하려면 needs:artifacts를 사용하십시오.
• trigger 작업에서 needs:pipeline:job을 사용할 수 없습니다.

needs:optional

파이프라인에 때때로 존재하지 않을 수 있는 작업을 필요로 하는 경우 optional: true를 needs 구성에 추가하십시오. 정의되지 않은 경우, optional: false가 기본값입니다.

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

• needs 항목이 optional: true이고 필요한 작업이 파이프라인에 존재하는 경우, 작업은 시작되기 전에 완료될 때까지 기다립니다.
• 필요한 작업이 존재하지 않는 경우, 작업은 다른 모든 요구 사항이 충족되면 시작할 수 있습니다.
• needs 섹션이 모든 선택적 작업만 포함하고, 파이프라인에 추가된 작업이 없는 경우, 작업은 즉시 시작됩니다 (빈 needs 항목인 경우와 동일하게 needs: []).
• 필요한 작업이 optional: false이지만 파이프라인에 추가되지 않는 경우, 파이프라인은 ‘작업이 파이프라인에 추가되지 않았지만 필요합니다’와 유사한 오류로 시작하지 못합니다.

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

needs:optional의 예:

build-job:
  stage: build

test-job1:
  stage: test

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

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

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

이 예에서:

• build-job, test-job1, test-job2는 단계 순서대로 시작합니다.
• 브랜치가 기본 브랜치인 경우, 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 "리눅스 빌드 중..."
  parallel:
    matrix:
      - PROVIDER: aws
        STACK:
          - monitoring
          - app1
          - app2

linux:rspec:
  stage: test
  needs:
    - job: linux:build
      parallel:
        matrix:
          - PROVIDER: aws
            STACK: app1
  script: echo "리눅스에서 rspec 실행 중..."

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

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

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

관련 주제:

• 여러 병렬화된 작업을 사용하여 필요로 하는 병렬화된 작업 지정.

추가 정보:

• needs:parallel:matrix의 매트릭스 변수 순서는 필요한 작업의 매트릭스 변수 순서와 일치해야 합니다. 예를 들어, 앞서 언급한 예시에서 linux:rspec 작업에서 변수의 순서를 반대로 바꾸면 유효하지 않습니다:

  linux:rspec:
    stage: test
    needs:
      - job: linux:build
        parallel:
          matrix:
            - STACK: app1        # 변수 순서가 `linux:build`와 일치하지 않아 유효하지 않습니다.
              PROVIDER: aws
    script: echo "리눅스에서 rspec 실행 중..."
  

pages

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

다음을 해야 합니다:

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

키워드 유형: 작업명.

pages의 예시:

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

위 예시는 my-html-content/ 디렉터리의 이름을 public/로 변경합니다. 이 디렉터리는 artifact로 내보내어 GitLab Pages와 함께 게시됩니다.

pages:publish

• GitLab 16.1에서 도입.

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

• GitLab 16.7에서 실험으로 도입되었습니다. 기본적으로 꺼져 있는 pages_multiple_versions_setting이라는 플래그로 실험-베타 지원으로 도입되었습니다.

플래그: Self-Managed GitLab에서 기본적으로 이 기능은 사용할 수 없습니다. 이 기능을 사용하려면 관리자가 pages_multiple_versions_setting이라는 피처 플래그를 활성화해야 합니다. GitLab.com 및 전용 GitLab에서는 이 기능을 사용할 수 없습니다. 이 기능은 아직 프로덕션 환경에 사용할 수 있는 상태가 아닙니다.

pages.path_prefix를 사용하여 GitLab Pages의 여러 배포를 위한 경로 접두어를 설정할 수 있습니다.

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

가능한 입력값:

• URL 문자로 이루어진 문자열.
• CI/CD 변수.
• 두 가지의 조합.

pages.path_prefix의 예시:

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

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

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개의 작업을 생성합니다.

추가 정보:

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

관련 주제:

• 큰 작업을 병렬화하기.

parallel:matrix

• GitLab 15.9에서 도입되었으며, 순열의 최대 개수가 50에서 200으로 증가했습니다.

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

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

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

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

• 변수 이름은 숫자, 문자 및 언더스코어(_)만 사용할 수 있습니다.
• 값은 문자열이거나 문자열의 배열이어야 합니다.
• 순열의 개수는 200을 초과할 수 없습니다.

parallel:matrix의 예시:

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

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

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

추가 세부 정보:

• parallel:matrix 작업은 변수 값들을 작업 이름에 추가하여 서로 다른 작업을 구분하지만, 큰 값은 이름이 제한을 초과시킬 수 있습니다:
  • 작업 이름은 255자 이하여야 합니다.
  • needs를 사용할 때, 작업 이름은 128자 이하여야 합니다.

관련 주제:

• 병렬 작업의 1차원 매트릭스 실행.
• 트리거된 병렬 작업의 매트릭스 실행.
• 각 병렬 매트릭스 작업에 대해 다른 러너 태그 선택하기.

추가 세부 정보:

• 동일한 변수 값을 사용하지만 다른 변수 이름으로 여러 매트릭스 구성을 만들 수 없습니다. 작업 이름은 변수 값에서 생성되며, 변수 이름이 아니기 때문에 동일한 값을 가진 매트릭스 항목은 서로 덮어씁니다.

  예를 들어, 이 test 구성은 동일한 작업의 두 시리즈를 생성하려고 하지만, OS2 버전이 OS 버전을 덮어씁니다:

  test:
    parallel:
      matrix:
        - OS: [ubuntu]
          PROVIDER: [aws, gcp]
        - OS2: [ubuntu]
          PROVIDER: [aws, gcp]
  

release

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

릴리스 작업은 release-cli에 액세스해야 하며, $PATH에 있어야 합니다.

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

Shell executor 또는 이와 유사한 경우, 러너(runner)가 등록된 서버에 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 태그를 푸시할 때.
• 코드 > 태그에서 UI를 사용하여 Git 태그를 추가할 때.

추가 세부 정보:

• trigger 작업을 제외한 모든 릴리스 작업은 script 키워드를 포함해야 합니다. 릴리스 작업은 스크립트 명령의 출력을 사용할 수 있습니다. 스크립트가 필요하지 않은 경우 플레이스홀더를 사용할 수 있습니다:

  script:
    - echo "릴리스 작업"
  

  이 요구 사항을 제거하기 위한 이슈가 있습니다.

• release 섹션은 script 키워드 후에, after_script 전에 실행됩니다.
• 릴리스는 작업의 본 스크립트가 성공한 경우에만 생성됩니다.
• 릴리스가 이미 존재하는 경우 갱신되지 않으며, release 키워드를 가진 작업이 실패합니다.

관련 주제:

• release 키워드를 사용한 CI/CD 예시.
• 단일 파이프라인에서 여러 릴리스 생성.
• 사용자 정의 SSL CA 인증서 사용.

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

• Introduced in GitLab 15.3. Supported by release-cli v0.12.0 or later. 태그가 존재하지 않는 경우 tag_message로 지정된 메시지로 주석이 달린 새 태그가 만들어집니다. 생략된 경우 가벼운 태그가 생성됩니다. 키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다. 가능한 입력값:

• 텍스트 문자열 release:tag_message의 예:

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

release:name

릴리스 이름입니다. 생략된 경우 release: tag_name의 값으로 채워집니다. 키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다. 가능한 입력값:

• 텍스트 문자열 release:name의 예:

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

release:description

릴리스의 긴 설명입니다. 키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다. 가능한 입력값:

• 긴 설명이 포함된 문자열
• 설명을 포함하는 파일의 경로
  • 파일 경로는 프로젝트 디렉터리($CI_PROJECT_DIR)를 기준으로 상대적이어야 합니다.
  • 파일이 심볼릭 링크인 경우, $CI_PROJECT_DIR에 있어야 합니다.
  • ./path/to/file 및 파일 이름에는 공백이 포함될 수 없습니다.

release:description의 예:

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

추가 세부 정보:

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

release:ref

release: tag_name이 아직 존재하지 않는 경우 릴리스를 위한 ref입니다. 키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다. 가능한 입력값:

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

release:milestones

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

release:released_at

릴리스가 준비된 날짜와 시간입니다. 가능한 입력값:

• ISO 8601 형식으로 표시된 따옴표로 둘러싸인 날짜 release:released_at의 예:

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

추가 세부 정보:

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

release:assets:links

릴리스에 자산 링크를 포함시키려면 release:assets:links를 사용하세요. release-cli 버전 v0.4.0 이상이 필요합니다. release:assets:links의 예:

assets:
  links:
    - name: '자산1'
      url: 'https://example.com/assets/1'
    - name: '자산2'
      url: 'https://example.com/assets/2'
      filepath: '/pretty/url/1' # 선택 사항
      link_type: '기타' # 선택 사항

resource_group

resource_group을 사용하여 동일 프로젝트의 다른 파이프라인에 대한 작업 간 상호 배타적인 작업 그룹을 만듭니다. 예를 들어, 동일한 리소스 그룹에 속하는 여러 작업이 동시에 대기 중인 경우, 작업이 한 번에 하나만 시작됩니다. 다른 작업은 resource_group이 사용 가능할 때까지 대기합니다. 리소스 그룹은 다른 프로그래밍 언어의 세마포어와 유사합니다.

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

환경 당 여러 리소스 그룹을 정의할 수 있습니다. 예를 들어, 물리적 장치로 배포하는 경우, 여러 물리적 장치를 가질 수 있습니다. 각 장치에 배포할 수 있지만 한 번에 한 장치당 하나의 배포만 발생합니다. 키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다. 가능한 입력값:

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

production으로-배포:
  script: 배포
  resource_group: production

이 예에서 두 개의 production으로-배포 작업은 동시에 실행되지 않습니다.

관련 주제:

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

retry

작업이 실패할 경우 작업을 최대 몇 번 다시 시도할지 설정하기 위해 retry를 사용합니다. 정의되지 않으면 기본값은 0이며 작업이 다시 시도되지 않습니다. 작업이 실패하면 작업은 두 번까지만 처리되어 성공하거나 재시도가 최대 횟수에 도달할 때까지 처리됩니다. 기본적으로 모든 실패 유형은 작업이 재시도됩니다. retry:when 또는 retry:exit_codes을 사용하여 재시도할 실패를 선택하세요. 키워드 유형: 작업 키워드. 작업 또는 기본 섹션의 일부로만 사용할 수 있습니다. 가능한 입력값:

• 0 (기본값), 1, 또는 2. retry의 예:

test:
  script: rspec
  retry: 2

test_advanced:
  script:
    - "코드 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`일 수 있습니다. 가능한 입력값:

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

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

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

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

러너 시스템 실패가 아닌 경우 작업이 재시도되지 않습니다.

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

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

retry:exit_codes

• GitLab 16.10에 도입되었습니다. 기본적으로 비활성화된 ci_retry_on_exit_codes 플래그가 함께 있습니다.
• GitLab 16.11에서 GitLab.com 및 Self-Managed형에 활성화되었습니다.

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

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

가능한 입력 값:

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

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

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

규칙은 파이프라인 생성 시 평가되며, 첫 번째 일치부터 순서대로 평가됩니다. 일치하는 경우, 작업은 구성에 따라 파이프라인에 포함 또는 제외됩니다.

rules는 규칙의 배열을 수용합니다. 각 규칙은 적어도 하나 이상을 가져야 합니다:

• if
• changes
• exists
• when

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

• allow_failure
• needs
• variables
• interruptible

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

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

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

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

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

추가 예시는 규칙으로 작업 실행 시기 지정을 참조하세요.

rules:if

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

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

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

가능한 입력 값:

• CI/CD 변수 표현식.

rules:if의 예시:

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

추가 세부 정보:

• 규칙이 일치하고 정의되지 않은 경우 규칙에서 when을 사용하지 않는 경우 작업의 when을 사용합니다. 이 경우 when은 정의되지 않은 경우 기본값으로 on_success를 사용합니다.
• rules에서 when 구성은 작업 수준에서의 when과 조합할 수 있습니다. 규칙의 when 구성은 작업 수준의 when에 우선합니다.
• script 섹션의 변수와 달리, 규칙 표현식의 변수는 항상 $VARIABLE로 서식이 지정됩니다.
  • rules:if를 include와 함께 사용하여 조건에 따라 다른 구성 파일을 추가할 수 있습니다.
• =~ 및 !~ 표현 내에서의 CI/CD 변수는 정규 표현식으로 평가됩니다.

관련 주제:

• rules에 대한 일반적인 if 표현식.
• 중복 파이프라인 피하기.
• Merge Request 파이프라인에서 rules 사용.

rules:changes

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

rules:changes:compare_to는 rules:changes:paths에 나열된 파일의 변경 사항을 비교할 대상을 지정하는 데 사용합니다.

키워드 유형: 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의 변경 사항이 refs/heads/branch1에 상대적으로 발생하고 파이프라인 소스가 Merge Request 이벤트인 경우에만 포함됩니다.

관련 주제:

• 브랜치가 비어 있는 경우 작업을 건너뛰도록 하려면 rules:changes:compare_to를 사용할 수 있습니다. (작업 건너뛰기)

rules:exists

• GitLab 15.6에서 CI/CD 변수 지원이 도입되었습니다.

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

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

가능한 입력:

• 파일 경로의 배열. 경로는 프로젝트 디렉터리($CI_PROJECT_DIR)를 기준으로 하며 외부 링크를 직접 사용할 수 없습니다. 파일 경로에는 glob 패턴과 CI/CD 변수를 사용할 수 있습니다.

rules:exists의 예시:

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

job은 리포지터리의 어느 곳에나 Dockerfile이 있을 때 실행됩니다.

추가 세부 정보:

• Glob 패턴은 루비의 File.fnmatch 및 flags인 File::FNM_PATHNAME | File::FNM_DOTMATCH | File::FNM_EXTGLOB으로 해석됩니다.
• 성능 상의 이유로 GitLab은 exists 패턴이나 파일 경로에 대해 최대 10,000개의 확인을 수행합니다. 10,000번째 확인 이후에는 패턴 형식의 exists 규칙이 항상 일치한다고 가정됩니다. 다시 말하면, exists 규칙은 10,000개 이상의 파일이 있는 프로젝트에서 항상 일치하거나 파일이 10,000개 미만이지만 exists 규칙이 10,000번 이상 확인될 경우에는 항상 일치합니다.
• rules:exists 섹션 당 최대 50개의 패턴이나 파일 경로를 정의할 수 있습니다.
• 작업 수준의 rules:exists에서 GitLab은 파이프라인을 실행하는 프로젝트와 참조에서 파일을 검색합니다. rules:exists와 함께 include 사용 시 GitLab은 include 섹션을 포함하는 파일의 프로젝트 및 참조에서 파일을 검색합니다. include 섹션을 포함하는 프로젝트는 다음과 같은 경우에 실행 중인 프로젝트와 다를 수 있습니다:
  • 중첩된 include 사용
  • 컴플라이언스 파이프라인

rules:when

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

rules:when rule이 if, changes, 또는 exists와 결합되지 않으면 작업의 rules를 평가할 때 항상 일치합니다.

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

가능한 입력값:

• on_success (기본값): 이전 단계의 작업 중 아무 것도 실패하지 않거나 allow_failure: true로 허용된 경우에만 작업을 실행합니다. on_success는 when을 if, changes, 또는 exists와 결합했을 때 기본 동작입니다.
• on_failure: 이전 단계에서 최소한 하나의 작업이 실패할 때만 작업을 실행합니다.
• never: 언제든지 이전 단계의 작업 상태에 관계없이 작업을 실행하지 않습니다.
• always: 언제든지 이전 단계의 작업 상태에 관계없이 작업을 실행합니다.
• manual: 매뉴얼 작업으로 파이프라인에 작업을 추가합니다. rules:when을 manual과 함께 사용할 때 allow_failure의 기본값은 false입니다.
• delayed: 지연 작업으로 파이프라인에 작업을 추가합니다.

rules:when의 예시:

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

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

• 기본 브랜치에서 when: on_success로 추가됩니다. 이는 when이 정의되지 않은 경우의 기본 동작입니다.
• 기능 브랜치에서는 지연 작업으로 추가됩니다.
• 그 외의 경우에는 매뉴얼 작업으로 추가됩니다.

rules:allow_failure

rules에서 allow_failure: true를 사용하여 작업을 실패로 종료하지 않고 허용할 수 있습니다.

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

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

가능한 입력값:

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

rules:allow_failure의 예시:

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

만약 규칙이 일치하는 경우, 해당 작업은 allow_failure: true를 가진 매뉴얼 작업이 됩니다.

추가 상세:

• rule-level의 rules:allow_failure은 job-level의 allow_failure을 오버라이드하며, 특정 rule이 작업을 트리거하는 경우에만 적용됩니다.

rules:needs

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

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

가능한 입력값:

• 작업 이름을 나타내는 문자열 배열.
• 작업 이름과 추가적인 attribute를 선택적으로 가진 해시.
• 조건이 충족되었을 때 작업 needs를 없음으로 설정하기 위해 빈 배열([])을 사용합니다.

rules:needs의 예시:

build-dev:
  stage: build
  rules:
    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH
  script: echo "Feature branch, so building dev version..."

build-prod:
  stage: build
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
  script: echo "Default branch, so building prod version..."

tests:
  stage: test
  rules:
    - if: $CI_COMMIT_BRANCH != $CI_DEFAULT_BRANCH
      needs: ['build-dev']
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
      needs: ['build-prod']
  script: echo "Running dev specs by default, or prod specs when default branch..."

이 예시에서:

• 파이프라인이 기본 브랜치가 아니므로 첫 번째 조건이 일치하고, specs 작업은 build-dev 작업이 필요합니다.
• 파이프라인이 기본 브랜치이므로 두 번째 조건이 일치하고, specs 작업은 build-prod 작업이 필요합니다.

추가 상세:

• rules에서 needs는 job-level에서 정의된 needs를 오버라이드합니다. 오버라이드된 경우, 동작은 job-level needs와 동일합니다.
• rules에서 needs는 artifacts와 optional을 수용할 수 있습니다.

rules:variables

특정 조건에 대한 변수를 정의하기 위해 variables를 rules에서 사용합니다.

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

가능한 입력값:

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

rules:variables의 예시:

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

rules:interruptible

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

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

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

가능한 입력값:

• true 또는 false.

rules:interruptible의 예시:

job:
  script: echo "Hello, Rules!"
  interruptible: true
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      interruptible: false  # job level에서 정의된 interruptible을 오버라이드합니다.
    - when: on_success

추가 상세:

• rule-level의 rules:interruptible은 job-level의 interruptible을 오버라이드하며, 특정 rule이 작업을 트리거하는 경우에만 적용됩니다.

script

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

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

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

가능한 입력값:

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

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

script의 예시:

job1:
  script: "bundle exec rspec"

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

추가 상세:

• 이러한 특수 문자를 script에서 사용할 때는 반드시 작은 따옴표(')나 큰 따옴표(")를 사용해야 합니다.
• 0이 아닌 종료 코드를 무시하도록 설정할 수 있습니다.
• script의 출력을 쉽게 확인할 수 있도록 색 코드를 사용할 수 있습니다.
• 사용자 정의 접기 가능한 섹션을 만들어 작업 로그 출력을 단순화할 수 있습니다.

비밀

CI/CD 비밀을 지정하도록 비밀을 사용하여 다음과 같은 작업을 수행합니다:

• 외부 비밀 제공 업체에서 검색합니다.
• CI/CD 변수로 작업에서 사용할 수 있도록 (기본적으로 file 타입).

비밀:보울트

• generic 엔진 옵션은 GitLab Runner 16.11에서 소개되었습니다.

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

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

가능한 입력:

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

비밀:보울트의 예시:

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

이 구문을 간소화할 수 있습니다. 간소화된 구문에서 engine:name과 engine:path는 모두 기본적으로 kv-v2로 설정됩니다:

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

간소화된 구문에서 사용자 정의 비밀 엔진 경로를 지정하려면 @로 시작하는 접미사를 추가하면 됩니다: