• 키워드
• Global keywords
  • default
  • include
    • include:component
    • include:local
    • include:project
    • include:remote
    • include:template
    • include:inputs
    • include:rules
  • 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
• Job keywords
  • 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: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
  • pages:pages.expire_in
  • parallel
    • parallel:matrix
  • 릴리스
    • 릴리스:tag_name
    • 릴리스:tag_message
    • 릴리스:name
    • 릴리스: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:exists:paths
      • rules:exists:project
    • rules:when
    • rules:allow_failure
    • rules:needs
    • rules:variables
    • rules:interruptible
  • run
  • script
  • secrets
    • secrets:vault
    • secrets:gcp_secret_manager
    • secrets:azure_key_vault
    • secrets:file
    • secrets:token
  • services
    • 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
  • manual_confirmation
• 사용되지 않는 키워드
  • 전역으로 정의 된 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-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	Identity federation을 사용하여 써드 파티 서비스에 인증.
  image	Docker 이미지 사용.
  inherit	모든 작업이 상속하는 전역 기본 값 선택.
  interruptible	더 신속한 실행에 의해 불필요하게 해지된 경우 작업을 취소할 수 있는지 여부 정의.
  manual_confirmation	수동 작업을 위한 사용자 정의 확인 메시지 정의.
  needs	스테이지 순서보다 먼저 작업을 실행합니다.
  pages	GitLab Pages에서 사용할 작업 결과 업로드.
  parallel	작업의 병렬 실행 횟수.
  release	Runner가 릴리스 객체를 생성하도록 지시합니다.
  resource_group	작업 동시성 제한.
  retry	실패시 작업을 자동으로 재시도할 수 있는 시간 및 횟수 정의.
  rules	작업의 선택된 속성을 평가하고 결정하는 조건 목록 및 작업이 작성되었는지 여부 목록.
  script	Runner에서 실행되는 셸 스크립트.
  run	Runner에서 실행되는 구성.
  secrets	작업이 필요로 하는 CI/CD 비밀.
  services	Docker 서비스 이미지 사용.
  stage	작업 스테이지 정의.
  tags	러너를 선택하기 위해 사용되는 태그 목록.
  timeout	프로젝트 전체 설정보다 우선하는 사용자 정의 작업 수준 타임아웃 정의.
  trigger	하위 파이프라인 트리거 정의.
  variables	작업 레벨에서 작업 변수 정의.
  when	작업을 실행할 시기.

Global keywords

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

default

• GitLab 16.4에서 id_tokens가 소개되었습니다.

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

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

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

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

default 예시:

default:
  image: ruby:3.0
  retry: 2

rspec:
  script: bundle exec rspec

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

이 예시에서:

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

추가 세부정보:

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

include

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

또한 중앙 저장소에 템플릿 파일을 저장한 다음 프로젝트에 포함시킬 수도 있습니다.

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

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

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

키워드 유형: Global 키워드.

가능한 입력: include 하위 키:

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

그리고 선택적으로:

• include:inputs
• include:rules

추가 세부 정보:

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

include:component

include:component를 사용하여 CI/CD 구성 요소를 파이프라인 구성에 추가합니다.

키워드 유형: Global 키워드.

가능한 입력: CI/CD 구성 요소의 전체 주소. 형식은 다음과 같습니다: <fully-qualified-domain-name>/<project-path>/<component-name>@<specific-version>.

include:component의 예시:

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

관련 주제:

• CI/CD 구성 요소 사용.

include:local

include:local을 사용하여 구성 파일이 포함된 저장소와 브랜치와 동일한 위치에 있는 파일을 포함합니다. 심볼릭 링크 대신 include:local을 사용합니다.

키워드 유형: Global 키워드.

가능한 입력:

루트 디렉토리(/)에 상대적인 전체 경로:

• YAML 파일은 .yml 또는 .yaml 확장자를 가져야 합니다.
• 파일 경로에 와일드카드 * 및 **를 사용할 수 있습니다.
• 특정 CI/CD 변수를 사용할 수 있습니다.

include:local의 예시:

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

더 짧은 구문을 사용하여 경로를 정의할 수도 있습니다:

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

추가 세부 정보:

• .gitlab-ci.yml 파일 및 로컬 파일은 동일한 브랜치에 있어야 합니다.
• Git 서브모듈 경로를 통해 로컬 파일을 포함할 수는 없습니다.
• include 구성은 항상 include 키워드를 포함하는 파일의 위치를 기준으로 평가되며, 파이프라인을 실행하는 프로젝트를 기준으로 하지 않습니다. 중첩된 include이 다른 프로젝트에 있는 구성 파일에 있는 경우, include: local은 다른 프로젝트에서 파일을 확인합니다.

include:project

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

키워드 유형: Global 키워드.

가능한 입력:

• include:project: 전체 GitLab 프로젝트 경로.
• include:file: 루트 디렉토리(/)에 상대적인 전체 파일 경로 또는 파일 경로 배열. YAML 파일은 .yml 또는 .yaml 확장자를 가져야 합니다.
• include:ref: 선택 사항. 파일을 가져올 ref. 지정되지 않으면 프로젝트의 HEAD가 기본값입니다. 특정 CI/CD 변수를 사용할 수 있습니다.

include:project의 예시:

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

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

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

추가 세부 정보:

• include 구성은 항상 include 키워드를 포함하는 파일의 위치를 기준으로 평가되며, 파이프라인을 실행하는 프로젝트를 기준으로 하지 않습니다. 중첩된 include이 다른 프로젝트에 있는 구성 파일에 있는 경우, include:local은 다른 프로젝트에서 파일을 확인합니다.
• 파이프라인이 시작될 때, 모든 방법으로 포함된 .gitlab-ci.yml 파일 구성이 평가됩니다. 구성은 시간에 따라 데이터베이스에 남게되어 있습니다. GitLab은 참조된 .gitlab-ci.yml 파일 구성이 변경되지 않으며 다음 파이프라인 시작 전까지는 변경 사항을 반영하지 않습니다.
• 다른 비공개 프로젝트에서 YAML 파일을 포함하는 경우, 파이프라인을 실행하는 사용자는 두 프로젝트의 멤버이어야 하며 파이프라인을 실행할 적절한 권한을 가지고 있어야 합니다. 포함된 파일 중 하나에 액세스 권한이 없는 경우 not found or access denied 오류가 표시될 수 있습니다.
• 다른 프로젝트의 CI/CD 구성 파일을 포함할 때 주의하세요. CI/CD 구성 파일이 변경되면 파이프라인이나 알림이 트리거되지 않습니다. 이는 보안적인 측면에서 제 3자 종속성을 가져오는 것과 유사합니다. ref를 고려할 때 다음을 고려하세요:
  • 가장 안정적인 옵션일 것으로 예상되는 특정 SHA 해시를 사용하세요. 원하는 커밋이 참조되도록 하기 위해 전체 40자 SHA 해시를 사용하세요. ref의 짧은 SHA 해시를 사용하면 모호할 수 있으므로 주의하세요.
  • 다른 프로젝트의 ref에 보호된 브랜치 및 보호된 태그 규칙을 적용하세요. 보호된 태그와 브랜치는 변경이 발생하기 전에 변경 관리를 거쳐야 할 가능성이 있습니다.

include:remote

include:remote를 사용하여 다른 위치의 파일을 포함할 수 있습니다.

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

가능한 입력값:

HTTP/HTTPS GET 요청으로 접근 가능한 공개 URL:

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

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

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:inputs

• GitLab 15.11에서 베타 기능으로 도입되었습니다.
• GitLab 17.0에서 일반적으로 사용 가능한 상태가 되었습니다.

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

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

가능한 입력값: 문자열, 숫자 값 또는 부울 값.

include:inputs의 예시:

include:
  - local: "custom_configuration.yml"
    inputs:
      website: "내 웹사이트"

이 예시에서:

• custom_configuration.yml에 포함된 구성은 파이프라인에 추가되며, 포함된 구성의 website 입력이 내 웹사이트 값으로 설정됩니다.

추가 세부 정보:

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

관련 주제:

• include를 사용할 때 입력 값을 설정하는 방법에 대한 자세한 정보는 여기를 확인하세요.

include:rules

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

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

가능한 입력값: 다음 rules 하위 키:

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

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

include:rules의 예시:

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

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

이 예시에서, INCLUDE_BUILDS 변수가:

• true이면, build_jobs.yml 구성이 파이프라인에 포함됩니다.
• true이 아니거나 존재하지 않으면, build_jobs.yml 구성은 파이프라인에 포함되지 않습니다.

관련 주제:

• 다음과 같이 include를 사용하는 예시:
  • rules:if.
  • rules:changes.
  • rules:exists.

stages

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

stages를 사용하여 작업 그룹을 포함하는 단계를 정의할 수 있습니다. 작업에서 특정 단계에서 실행되도록 하려면 stage를 사용하십시오.

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

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

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

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

파이프라인에 .pre 또는 .post 단계에 있는 작업만 있는 경우, 실행되지 않습니다. 반드시 다른 단계에 최소한 하나의 작업이 있어야 합니다. .pre 및 .post 단계는 필수 파이프라인 설정에서 프로젝트 파이프라인 작업 이전 또는 이후에 실행해야 하는 규정 준수 작업을 정의하는 데 사용할 수 있습니다.

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

stages의 예시:

stages:
  - build
  - test
  - deploy

이 예시에서:

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

작업 중 하나라도 실패하면, 파이프라인은 failed로 표시되고, 이후 단계의 작업은 시작되지 않습니다. 현재 단계의 작업은 중단되지 않으며 계속 실행됩니다.

추가 세부 정보:

• 작업이 stage를 지정하지 않은 경우, 작업은 test 단계에 할당됩니다.
• 단계가 정의되었지만 사용되는 작업이 없는 경우, 해당 단계는 파이프라인에서 보이지 않습니다.
  • 규정 준수 파이프라인 구성에서:
    • 단계는 규정에 정의되지만 작업 정의에 사용되지 않으면 숨겨집니다.
    • 개발자가 작업 정의에서 사용하는 경우 정의된 단계는 보이게 됩니다.

관련 주제:

• 작업을 이전보다 빨리 시작하고 단계 순서를 무시하려면 needs 키워드를 사용하십시오.

workflow

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

workflow 구성에서 사전 정의된 CI/CD 변수를 사용할 수 있지만, 작업 시작 시에만 정의된 변수는 사용할 수 없습니다.

관련 주제:

• workflow: rules 예제
• 브랜치 파이프라인과 병합 요청 파이프라인 간 전환하기(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 및 온프레미스에 활성화.
• 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 및 온프레미스에 활성화.
• GitLab 15.8에서 일반적으로 사용 가능. pipeline_name 플래그 제거됨.

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

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

가능한 입력:

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

workflow:name 예제:

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

workflow:
  name: "Branch에 대한 Pipeline: $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과 유사하지만, 전체 파이프라인이 생성되는지 여부를 제어합니다.

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

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

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

workflow:rules의 예시:

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

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

• 병합 요청
• 기본 브랜치.

추가 세부 정보:

• 만약 규칙이 기본 브랜치 이외의 브랜치 파이프라인 및 병합 요청 파이프라인 모두와 매치된다면, 중복 파이프라인이 발생할 수 있습니다.

관련 주제:

• workflow:rules에 대한 일반적인 if 절.
• 병합 요청 파이프라인 실행에 rules 사용.

workflow:rules:variables

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

조건이 맞을 때, 변수가 생성되고 파이프라인의 모든 작업에서 사용할 수 있습니다. 만약 변수가 이미 전역 수준에서 정의되어 있다면, workflow 변수가 우선하고 전역 변수를 재정의합니다.

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

가능한 입력값: 변수명과 값의 쌍:

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

workflow:rules:variables의 예시:

variables:
  DEPLOY_VARIABLE: "default-deploy"

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

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

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

기본 브랜치인 경우:

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

feature 브랜치인 경우:

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

다른 브랜치인 경우:

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

추가 세부 정보:

• workflow:rules:variables는 전역 변수가 되어 모든 작업에서 사용할 수 있습니다. 기본적으로 trigger 작업에서는 하위 파이프라인으로 변수를 전달합니다. 만약 하위 파이프라인에서 동일한 변수를 사용한다면, 상위 변수 값에 의해 변수가 덮어씌워집니다. 각 프로젝트의 파이프라인 구성에서 고유한 변수명을 사용하거나, 하위 파이프라인으로 전달하고자 하는 정확한 변수를 나열하고 inherit:variables를 사용해야 합니다.

workflow:rules:auto_cancel

• GitLab 16.8에서 도입, ci_workflow_auto_cancel_on_new_commit이라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
• GitLab 16.9에서 GitLab.com 및 온-프레미스에서 활성화되었습니다.
• GitLab 16.10에서 일반적으로 사용 가능해졌으며, ci_workflow_auto_cancel_on_new_commit 플래그가 제거되었습니다.
• GitLab 16.10에서 on_job_failure 옵션을 도입했으며, auto_cancel_pipeline_on_job_failure이라는 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
• GitLab 16.11에서 on_job_failure 옵션을 일반적으로 사용 가능하게 되었으며, auto_cancel_pipeline_on_job_failure 플래그가 제거되었습니다.

workflow:rules:auto_cancel을 사용하여 workflow:auto_cancel:on_new_commit 또는 workflow:auto_cancel:on_job_failure 기능을 구성할 수 있습니다.

가능한 입력값:

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

workflow:rules:auto_cancel의 예시:

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

test-job1:
  script: sleep 10
  interruptible: false

test-job2:
  script: sleep 10
  interruptible: true

이 예시에서 workflow:auto_cancel:on_new_commit 는 기본적으로 interruptible로 설정되어 있고, workflow:auto_cancel:on_job_failure 는 기본적으로 모든 작업에 all로 설정되어 있습니다. 하지만 만약 보호된 브랜치에 대한 파이프라인이 실행되면, 규칙이 기본값을 on_new_commit: none 및 on_job_failure: none으로 덮어씁니다. 예를 들어, 다음을 실행하는 경우:

• 비보호된 브랜치와 새 커밋이 푸시된 경우, test-job1은 계속 실행되고 test-job2는 취소됩니다.
• 보호된 브랜치와 새 커밋이 푸시된 경우, test-job1 및 test-job2 모두 계속 실행됩니다.

spec:
  inputs:
    environment:
    job-stage:
---
GitLab 15.11에서 베타 기능으로 소개되었습니다.

`spec` 섹션을 추가하여 `include` 키워드를 사용하여 파이프라인에 구성이 추가될 때
파이프라인의 동작을 구성하는 YAML 파일의 헤더에 `spec` 섹션을 추가합니다.

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

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

헤더 섹션 밖에서 값에 참조하기 위해 보간 형식 `$[[ inputs.input-id ]]`을 사용합니다.
입력값은 파이프라인 생성시 구성을 가져오고, `.gitlab-ci.yml` 파일의 내용과 병합되기 전에 평가 및 보간됩니다.

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

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

**`spec:inputs` 예시**:

```yaml
spec:
  inputs:
    environment:
    job-stage:
---

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

추가 정보:

• 기본값을 설정하려면 spec:inputs:default를 사용해야합니다.
• spec:inputs를 사용하여 입력 매개변수를 정의하세요.

spec:inputs:default

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

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

기본값이 없을 경우 default: ''를 사용하세요.

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

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

spec:inputs:default 예시:

spec:
  inputs:
    website:
    user:
      default: "test-user"
    flags:
      default: ""
---
# 파이프라인 구성은 계속됩니다...

이 예시에서:

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

spec:inputs:description

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

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를 모두 사용하지만, 기본값이 목록에 나열된 옵션 중 하나가 아닐 때.
  • 입력값이 options 및 regex를 모두 사용하지만, 기본값이 정규 표현식과 일치하지 않을 때.
  • 값이 type과 일치하지 않을 때 type은 string 또는 number 뿐입니다. options을 사용할 때 boolean이 아닙니다.

spec:inputs:regex

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

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

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

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

spec:inputs:regex 예시:

spec:
  inputs:
    version:
      regex: ^v\d\.\d+(\.\d+)$
---
# 파이프라인 구성은 계속됩니다...

이 예시에서 v1.0 또는 v1.2.3 입력값은 정규 표현식과 일치하여 검증을 통과합니다. v1.A.B 입력값은 정규 표현식과 일치하지 않기 때문에 검증에 실패합니다.

추가 정보:

• inputs:regex는 type을 string으로 설정했을 때만 사용할 수 있습니다.
• 정규 표현식을 / 문자로 둘러싸지 마십시오. 예를 들어 /regex.*/가 아닌 regex.*를 사용하세요.
• inputs:regex는 정규 표현식을 파싱하기 위해 RE2를 사용합니다.

##### `spec:inputs:type`

기본적으로 inputs는 문자열을 예상합니다. `spec:inputs:type`을 사용하여 inputs의 다른 필수 유형을 설정할 수 있습니다.

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

**가능한 inputs**: 다음 중 하나일 수 있습니다:

- `array`, [배열](../yaml/inputs.md#array-type)을 받아들이기 위해.
- `string`, 문자열 inputs을 받아들이기 위해 (정의되지 않았을 때 기본값).
- `number`, 숫자형 inputs만 받아들이기 위해.
- `boolean`, `true` 또는 `false` inputs만 받아들이기 위해.

**`spec:inputs:type`의 예시**:

```yaml
spec:
  inputs:
    job_name:
    website:
      type: string
    port:
      type: number
    available:
      type: boolean
    array_input:
      type: array
---
# 파이프라인 구성이 계속됩니다...

Job keywords

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

after_script

• after_script 명령은 GitLab 17.0에서 도입된 취소된 작업을 위해 실행합니다.

after_script을 사용하여 작업의 before_script 및 script 섹션이 완료된 후 마지막으로 실행할 명령 배열을 정의합니다. 또한 after_script 명령은 다음 상황에서 실행됩니다.

• 작업이 before_script 또는 script 섹션이 여전히 실행 중인 동안 취소될 때.
• 작업이 script_failure 실패 유형으로 실패했지만 다른 실패 유형은 아닐 때.

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

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

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

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

after_script의 예시:

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

추가 정보:

after_script에서 지정한 스크립트는 before_script 또는 script 명령에서 수행한 변경을 포함하여, 새 셸에서 실행됩니다. 이에 따라 다음과 같은 특징이 있습니다:

• 현재 작업 디렉터리는 기본값으로 설정되며( 러너가 Git 요청을 처리하는 방식을 정의하는 변수에 따라), 이외에는 before_script 또는 script 스크립트로 설치 한 소프트웨어와 같은 작업 디렉터리 외의 변경 사항(러너 실행자에 따라)에 대한 액세스 권한이 없습니다.
• 별도의 시간 제한이 있습니다. GitLab 러너 16.4 이상에서는 기본적으로 5 분이며, RUNNER_AFTER_SCRIPT_TIMEOUT 변수로 구성할 수 있습니다. GitLab 16.3 이하에서는 타임아웃이 하드 코딩되어 5 분입니다.
• 작업의 종료 코드에 영향을주지 않습니다. script 섹션이 성공하고 after_script가 시간 초과되거나 실패하면 작업은 코드 0 (작업 완료)로 종료됩니다.
• after_script에서 CI/CD 작업 토큰을 사용하는 데에는 알려진 문제가 있습니다. after_script에서 인증에 작업 토큰을 사용할 수는 있지만, 작업을 취소하면 토큰은 즉시 무효화됩니다. 자세한 내용은 이슈를 참조하세요.

작업 시간이 초과되면 after_script 명령이 실행되지 않습니다. 시간 초과된 작업에 대한 after_script 명령을 실행하는 것을 지원하려면 이슈가 존재합니다.

관련 주제:

• default와 after_script 함께 사용. 모든 작업이 실행된 후에 실행해야하는 기본 명령 배열을 정의합니다.
• 작업이 취소되면 after_script 명령을 건너뛸 수 있습니다.
• 0이 아닌 종료 코드 무시.
• after_script에 색상 코드 사용하여 작업 로그를 쉽게 검토할 수 있습니다.
• 사용자 지정 축소 가능한 섹션](script.md#custom-collapsible-sections)을 만들어 작업 로그 출력을 단순화합니다.

allow_failure

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

• 파이프라인을 계속 실행하려면 allow_failure: true를 사용합니다.
• 파이프라인을 계속 실행하지 않으려면 allow_failure: false를 사용합니다.

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

이러한 경고는 다음 경우에 표시됩니다.

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

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

• 수동 작업을위한 경우 true.
• rules 내에서 when: manual을 사용하는 작업의 경우 false.
• 그 외의 모든 경우에 대해 false.

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

가능한 inputs:

• 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 단계의 작업을 시작할 수 있습니다.

추가 정보:

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

allow_failure:exit_codes

allow_failure:exit_codes를 사용하여 작업이 실패해도 되는 경우를 제어합니다. 작업은 나열된 종료 코드 중 어떤 것이든 allow_failure: true라고 표시되면, 다른 종료 코드의 경우 allow_failure는 false입니다.

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

가능한 입력:

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

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)를 기준으로 상대적이며 외부로 직접 링크될 수 없습니다.

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

가능한 입력:

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

CI/CD 변수들은 여기서 사용 가능합니다. where_variables_can_be_used.md.

artifacts:paths의 예시:

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

이 예시는 .config 및 binaries 디렉토리 내의 모든 파일을 포함하는 아티팩트를 생성합니다.

추가적인 세부 정보:

• artifacts:name과 함께 사용되지 않을 경우, 아티팩트 파일은 artifacts로 명명됩니다. 이 파일은 다운로드될 때 artifacts.zip로 변환됩니다.

관련 주제:

• 특정 작업이 다른 작업으로부터 아티팩트를 가져오는 것을 제한하려면, dependencies를 참조하세요.
• 작업 아티팩트 생성.

artifacts:exclude

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

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

가능한 입력:

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

artifacts:exclude의 예시:

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

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

추가적인 세부 정보:

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

관련 주제:

• 작업 아티팩트에서 파일 제외하기.

artifacts:expire_in

expire_in을 사용하여 작업 아티팩트가 만료되어 삭제되기 전에 저장되는 기간을 지정합니다. expire_in 설정은 다음과 같은 것에 영향을 주지 않습니다:

• 최신 작업의 아티팩트는 만료되지 않습니다. 단, 최신 작업 아티팩트의 유지를 끄는 것이 설정되어 있다면(프로젝트 레벨 또는 인스턴스 전체), 만료되어 삭제됩니다.

만료 후, 아티팩트는 기본값으로 시간당 삭제됩니다(cron 작업을 사용) 그리고 더 이상 접근할 수 없습니다.

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

가능한 입력: 만료 시간. 단위가 제공되지 않은 경우, 시간은 초로 표시됩니다. 유효한 값은 다음과 같습니다:

• '42'
• 42 seconds
• 3 mins 4 sec
• 2 hrs 20 min
• 2h20min
• 6 mos 1 day
• 47 yrs 6 mos and 4d
• 3 weeks and 2 days
• never

artifacts:expire_in의 예시:

job:
  artifacts:
    expire_in: 1 week

추가적인 세부 정보:

• 만료시간은 아티팩트가 GitLab에 업로드되고 저장되는 시점부터 시작됩니다. 유효시간이 정의되어 있지 않으면, 인스턴스 전체 설정으로 기본화됩니다.
• 만료 날짜를 무시하고 아티팩트를 자동으로 삭제되는 것을 방지하려면:
  • 작업 페이지에서 유지를 선택하세요.
  • expire_in 값을 never로 설정하세요.
• 유효시간이 너무 짧으면, 긴 파이프라인의 후반 단계의 작업들은 이전 작업에서 만료된 아티팩트를 가져오려고 합니다. 아티팩트가 만료되면, 그것들을 가져오려 하는 작업들은 needed artifacts를 검색할 수 없다 오류로 실패합니다. 만료시간을 더 길게 할 수도 있고, 나중의 작업에서 dependencies를 사용하여 만료된 아티팩트를 가져오지 않도록 할 수도 있습니다.

artifacts:expose_as

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

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

가능한 입력:

• 병합 요청 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은 작동하지 않음.
• 병합 요청 당 최대 10개의 작업 아티팩트를 노출할 수 있습니다.
• Glob 패턴은 지원되지 않습니다.
• 디렉토리가 지정되고 디렉토리에 둘 이상의 파일이 있는 경우, 링크는 작업 아티팩트 브라우저로 이동합니다.
• GitLab Pages가 활성화된 경우, GitLab은 아티팩트를 자동으로 렌더링합니다. 이때 아티팩트는 다음 확장자 중 하나를 가진 단일 파일인 경우에 해당됩니다:
  • .html 또는 .htm
  • .txt
  • .json
  • .xml
  • .log

관련 주제:

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

artifacts:name

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

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

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

가능한 입력:

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

artifacts:name의 예:

현재 job의 이름으로 아카이브를 생성하는 경우:

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

관련 주제:

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

artifacts:public

• GitLab 15.10에서 업데이트되었습니다. 15.10 이전에 artifacts:public으로 생성된 아티팩트는 이 업데이트 이후에는 비공개로 보장되지 않을 수 있습니다.
• GitLab 16.7에서 일반 사용 가능합니다. 피처 플래그 non_public_artifacts가 제거되었습니다.

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

artifacts:public을 사용하여 작업 아티팩트를 공개적으로 이용 가능하게 할지를 결정하세요.

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

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

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

가능한 입력:

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

artifacts:public의 예:

job:
  artifacts:
    public: false

artifacts:access

• GitLab 16.11에서 도입되었습니다.

artifacts:access를 사용하여 작업 아티팩트에 액세스할 수 있는 사용자를 결정하세요.

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

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

가능한 입력:

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

artifacts:access의 예:

job:
  artifacts:
    access: "developer"

추가 정보:

• artifacts:access는 모든 artifacts:reports에도 영향을 미치므로 리포트용 아티팩트에 대한 액세스를 제한할 수도 있습니다.

artifacts:reports

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

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

가능한 입력:

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

artifacts:reports의 예:

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

추가 정보:

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

artifacts:untracked

artifacts:untracked를 사용하여 Git 미추적 파일을 모두 아티팩트로 추가합니다 (artifacts:paths에서 정의된 경로와 함께). artifacts:untracked는 .gitignore의 구성을 무시하므로 .gitignore에 맞는 아티팩트가 포함됩니다.

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

가능한 입력:

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

artifacts:untracked 예시:

모든 Git 미추적 파일 저장:

job:
  artifacts:
    untracked: true

관련 주제:

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

artifacts:when

artifacts:when을 사용하여 작업 실패 시 아티팩트를 업로드하거나 실패에 관계없이 업로드합니다.

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

가능한 입력:

• on_success (기본값): 작업이 성공했을 때만 아티팩트를 업로드합니다.
• on_failure: 작업이 실패했을 때만 아티팩트를 업로드합니다.
• always: 항상 아티팩트를 업로드합니다(작업 시간이 초과되지 않은 경우). 예를 들어, 실패한 테스트를 해결하기 위해 업로드된 아티팩트.

artifacts:when 예시:

job:
  artifacts:
    when: on_failure

추가 세부 정보:

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

before_script

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

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

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

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

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

before_script 예시:

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

추가 세부 정보:

• before_script에서 지정한 스크립트는 주 script에서 지정한 스크립트와 연결되어 단일 쉘에서 함께 실행됩니다.
• before_script을 최상위 수준에서 사용하나 default 섹션에는 사용하지 않는 것이 추천되지 않습니다.

관련 주제:

• default로 before_script을 사용하여 모든 작업의 script 명령어 전에 실행되어야 하는 기본 배열을 정의할 수 있습니다.
• 비-제로 종료 코드를 무시합니다.
• before_script와 함께 색상 코드 사용하여 작업 로그를 확인하기 쉽게 만듭니다.
• 사용자 정의 축소 가능한 섹션을 만들어 작업 로그 출력을 단순화합니다.

캐시

• 도입됨 in GitLab 15.0, caches are not shared between protected and unprotected branches.

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

캐시는 다음과 같습니다:

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

특정 작업에서 캐싱을 비활성화할 수 있으며, 예를 들어 다음을 덮어쓸 수 있습니다:

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

캐시에 대한 자세한 정보는 GitLab CI/CD의 캐싱을 참조하십시오.

cache:paths

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

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

가능한 입력:

• 프로젝트 디렉터리($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:key

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

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

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

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

가능한 입력값:

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

cache:key의 예시:

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

추가 세부 정보:

• 셸 스크립트를 실행하기 위해 Windows Batch를 사용하는 경우 $를 %로 대체해야 합니다. 예: key: %CI_COMMIT_REF_SLUG%

• cache:key 값에 다음이 포함될 수 없습니다:

  • / 문자 또는 해당 URI 인코딩 %2F
  • . 문자(어떤 수의) 또는 해당 URI 인코딩 %2E만
• 캐시는 작업 간에 공유되므로 서로 다른 작업에 대해 다른 경로를 사용하는 경우, 다른 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 "This job uses a cache."
  cache:
    key:
      files:
        - Gemfile.lock
        - package.json
  paths:
    - vendor/ruby
    - node_modules

이 예시는 Ruby 및 Node.js 종속성을 위한 캐시를 생성합니다. 해당 캐시는 Gemfile.lock 및 package.json 파일의 현재 버전에 바인딩됩니다. 이 파일 중 하나가 변경될 때마다 새 캐시 키가 계산되고 새 캐시가 생성됩니다. cache:key:files로 같은 Gemfile.lock 및 package.json을 사용하는 이후 작업 실행은 종속성을 다시 구축하는 대신 새 캐시를 사용합니다.

추가 세부 정보:

• 캐시 key는 각 목록된 파일이 변경된 가장 최신의 커밋에서 계산된 SHA입니다. 어떤 파일도 어떤 커밋에서 변경되지 않으면 폴백 키는 default입니다.

cache:key:prefix

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

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

가능한 입력값:

• 문자열
• 미리 정의된 변수
• 둘 다의 조합

cache:key:prefix의 예시:

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

예를 들어, $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로 체크아웃에 추가되지 않은 파일

추적되지 않은 파일을 캐시에 저장하면 작업이 다음을 다운로드할 때 예상하지 못한 큰 캐시가 생성될 수 있습니다:

• 보통 추적되지 않는 종속성(예: 젬이나 노드 모듈)
• 다른 작업에서 가져온 아티팩트. 아티팩트에서 추출된 파일은 기본적으로 추적되지 않습니다.

키워드 유형: 작업 키워드로, 작업의 일부 또는 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를 사용하여 protected와 unprotected 브랜치 간에 공유되는 캐시를 설정합니다.

경고: true로 설정하면, 보호된 브랜치에 액세스 권한이 없는 사용자도 보호된 브랜치에서 사용하는 캐시 키를 읽거나 쓸 수 있습니다.

Keyword 타입: Job keyword. job의 일부로만 사용하거나 default 섹션에서만 사용할 수 있습니다.

가능한 입력:

• true 또는 false (기본값).

cache:unprotect의 예시:

rspec:
  script: test
  cache:
    unprotect: true

cache:when

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

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

Keyword 타입: Job keyword. 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를 사용하세요.

같은 캐시를 사용하는 병렬 작업이 많이 실행되는 경우 pull 정책을 사용하세요. 이러한 정책은 작업 실행 속도를 높이고 캐시 서버의 부하를 줄입니다. push 정책을 사용하여 캐시를 빌드하세요.

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

Keyword 타입: Job keyword. job의 일부로만 사용하거나 default 섹션에서만 사용할 수 있습니다.

가능한 입력:

• pull
• push
• pull-push (기본값)
• CI/CD variables.

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를 사용하세요. 캐시는 fallback_keys 섹션에서 지정된 순서대로 검색됩니다.

Keyword 타입: Job keyword. 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입니다.

추가적인 세부 정보:

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

dast_configuration

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

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

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

• site_profile은 작업에서 사용할 사이트 프로필을 지정하는 데 사용됩니다.
• scanner_profile은 작업에서 사용할 스캐너 프로필을 지정하는 데 사용됩니다.

dast_configuration의 예시:

stages:
  - build
  - dast

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

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

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

추가 상세 정보:

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

관련 주제:

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

dependencies

dependencies 키워드를 사용하여 artifacts를 가져올 특정 작업 목록을 정의합니다. 지정된 작업은 모두 이전 단계에 있어야 합니다. 또한 작업을 전혀 아카이브하지 않도록 설정할 수도 있습니다.

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

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

가능한 입력값:

• artifacts를 가져올 작업의 이름들.
• 빈 배열([]), 작업에서 artifacts를 아예 다운로드하지 않도록 구성하기 위해.

dependencies의 예시:

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

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

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

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

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

이 예시에서 build osx와 build linux 두 작업이 artifacts를 가집니다. test osx가 실행될 때 build osx의 artifacts가 다운로드되어 빌드의 맥락에서 추출됩니다. test linux에 대해서도 build linux의 artifacts가 마찬가지로 진행됩니다.

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

추가 상세 정보:

• 작업이 완료되면 머지 요청, 환경 또는 배포 페이지에서 버튼을 선택하여 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

• GitLab 15.4에서 도입된CI/CD 변수 지원.

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

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

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

environment:kubernetes의 예시:

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

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

추가 세부 정보:

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

관련 토픽:

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

environment:deployment_tier

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 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은 파이프라인을 생성할 때:

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

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

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

추가 세부 정보:

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

관련 토픽:

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

hooks

hooks를 사용하여 작업 실행의 특정 단계에서 러너에서 실행할 명령어 목록을 지정합니다. Git 리포지토리를 검색하기 전과 같은 작업 실행의 특정 단계에서 사용합니다.

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

가능한 입력:

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

hooks:pre_get_sources_script

hooks:pre_get_sources_script를 사용하여 Git 리포지토리 및 모든 서브모듈을 복제하기 전에 러너에서 실행할 명령어 목록을 지정합니다. 이를 사용하여 다음과 같은 작업을 수행할 수 있습니다:

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

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

• Single line commands.
• 여러 줄에 걸친 긴 명령어.
• YAML 앵커.

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

hooks:pre_get_sources_script 예시:

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

관련 주제:

• GitLab Runner configuration

identity

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

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

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

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

• 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 integration.

id_tokens

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

가능한 입력:

• Token 이름과 해당 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

관련 주제:

• ID token authentication.
• Cloud services에 연결.
• Sigstore를 사용한 키리스 서명.

image

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

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

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

• <image-name> (latest 태그를 사용한 <image-name> 사용과 동일)
• <image-name>:<tag>
• <image-name>@<digest>

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

image 예시:

default:
  image: ruby:3.0

rspec:
  script: bundle exec rspec

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

이 예에서 ruby:3.0 이미지는 파이프라인의 모든 작업의 기본값입니다. rspec 2.7 작업은 기본값을 사용하지 않으며 작업별 image 섹션으로 기본값을 재정의합니다.

관련 주제:

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

image:name

작업이 실행되는 Docker 이미지의 이름입니다. image와 유사하게 사용됩니다.

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

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

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 "A single pull policy."
  image:
    name: ruby:3.0
    pull_policy: if-not-present

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

추가 세부 정보:

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

관련 주제:

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

inherit

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을 사용하여 전역 변수 키워드의 상속을 제어합니다.

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

가능한 입력값:

• true (기본값) 또는 false, 모든 전역 변수의 상속을 활성화 또는 비활성화합니다.
• 상속할 특정 변수의 목록.

inherit:variables의 예시:

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

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

job2:
  script: echo "This job inherits only the two listed global variables. It does not inherit 'VARIABLE3'."
  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 # the default behavior

stages:
  - stage1
  - stage2
  - stage3

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

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

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

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

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

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

workflow:
  auto_cancel:
    on_new_commit: interruptible

stages:
  - stage1
  - stage2
  - stage3

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

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

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

이 예시에서 새 파이프라인은 실행 중인 파이프라인을 시작된 경우 step-1 및 step-3을 취소합니다.

추가 세부 정보:

• 빌드 작업과 같이 작업이 시작된 후에 안전하게 취소할 수 있는 경우에만 interruptible: true를 설정하세요. 배포 작업은 일반적으로 취소되지 않아야 하며 부분 배포를 방지해야 합니다.
• 기본 동작이나 workflow:auto_cancel:on_new_commit: conservative를 사용할 때:
  • 아직 시작되지 않은 작업은 항상 interruptible: true로 간주됩니다. interruptible 구성은 작업이 시작된 후에만 고려됩니다.
  • 실행 중인 파이프라인은 모두 interruptible: true로 구성되었거나 interruptible: false가 한 번도 시작되지 않은 경우에만 취소됩니다. interruptible: false로 구성된 작업이 시작된 후에는 전체 파이프라인이 더 이상 중단되지 않습니다.
  • 파이프라인이 하향 파이프라인을 트리거했지만 하향 파이프라인에서 interruptible: false를 시작한 경우, 하향 파이프라인도 취소됩니다.
• 파이프라인에 .pre 스테이지와 needs: []를 가진 작업이 모두있는 경우, 파이프라인이 만들어지자마자 모두 시작됩니다. needs: []가있는 작업은 즉시 시작되며, .pre 스테이지의 작업도 즉시 시작됩니다.

needs

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

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

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

가능한 입력값:

• 작업의 배열 (최대 50개의 작업).
• 빈 배열([]), 파이프라인이 생성됨과 동시에 작업을 시작하도록 설정합니다.

needs의 예시:

linux:build:
  stage: build
  script: echo "Building linux..."

mac:build:
  stage: build
  script: echo "Building mac..."

lint:
  stage: test
  needs: []
  script: echo "Linting..."

linux:rspec:
  stage: test
  needs: ["linux:build"]
  script: echo "Running rspec on linux..."

mac:rspec:
  stage: test
  needs: ["mac:build"]
  script: echo "Running rspec on mac..."

production:
  stage: deploy
  script: echo "Running production..."
  environment: production

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

• 린터: 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입니다. 자세한 내용은 issue 350398을 참조하세요.
  • 온프레미스 인스턴스의 경우 기본 제한은 50입니다. 이 제한은 변경할 수 있습니다.
• needs가 parallel 키워드를 사용하는 작업을 참조하는 경우 병렬로 생성된 모든 작업에 종속되어 아티팩트를 기본적으로 모든 병렬 작업에서 다운로드합니다. 아티팩트의 이름이 동일한 경우에는 서로 덮어쓰고 마지막으로 다운로드된 아티팩트만 저장됩니다.
  • needs가 병렬 작업의 일부(모든 병렬 작업이 아닌 일부 병렬 작업에)를 참조하도록하려면 needs:parallel:matrix 키워드를 사용하세요.
• 작업을 구성하는 데 사용되는 only, except, 또는 rules으로 인해 needs가 추가되지 않을 가능성이 있는 작업을 참조하는 경우 파이프라인 생성에 실패할 수 있습니다. 실패한 파이프라인 생성을 해결하려면 needs:optional 키워드를 사용하세요.
• 파이프라인에 needs: []로 구성된 작업과 .pre 단계에있는 작업이있는 경우, 모두 파이프라인이 생성됨과 동시에 시작됩니다. needs: []가있는 작업은 즉시 시작되며, .pre 단계에있는 작업도 즉시 시작됩니다.

needs:artifacts

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

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

Keyword type: 작업 키워드. 작업의 일부로만 사용할 수 있습니다. 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 artifact를 다운로드합니다.
• test-job2 작업은 build_job2 artifact를 다운로드하지 않습니다.
• test-job3 작업은 artifacts가 true 또는 3개의 필요한 작업에 대해 기본값인 true 이기 때문에 3개의 build_job에서 artifact를 다운로드합니다.

추가 세부 정보:

• 동일한 작업 내에서 needs와 dependencies를 함께 사용해서는 안 됩니다.

needs:project

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

ref에 대한 파이프라인이 실행 중인 경우, needs:project를 가진 작업은 파이프라인이 완료될 때까지 기다리지 않습니다. 대신 artifact는 지정된 작업의 최신 성공 실행에서 다운로드됩니다.

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

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

가능한 입력값:

• needs:project: 네임스페이스와 그룹을 포함한 전체 프로젝트 경로.
• job: artifact를 다운로드할 작업.
• ref: artifact를 다운로드할 ref.
• artifacts: artifact를 다운로드하려면 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 작업에서 artifact를 다운로드합니다.

needs:project에서 CI/CD 변수를 사용할 수 있습니다. 예:

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

추가 세부 정보:

• 현재 프로젝트의 다른 파이프라인에서 artifact를 다운로드하려면 project를 현재 프로젝트와 동일하게 설정하되, 현재 파이프라인과 다른 ref를 사용해야 합니다. 동일한 ref에서 실행 중인 병렬 파이프라인은 artifact를 덮어쓸 수 있습니다.
• 파이프라인을 실행하는 사용자는 그룹 또는 프로젝트에 대해 적어도 Reporter 역할을 가져야 하거나 그룹/프로젝트가 공개적으로 보이도록 설정돼 있어야 합니다.
• trigger와 함께 동일한 작업에서 needs:project를 사용할 수 없습니다.
• needs:project를 사용하여 다른 파이프라인에서 artifact를 다운로드할 때, 해당 작업이 완료될 때까지 대기하지 않습니다. 작업이 완료될 때까지 대기하려면 needs 사용을 참고하세요. 작업이 필요한 job을 다운로드하려는 작업이 artifact를 다운로드하기 전에 해당 파이프라인에서 필요한 job이 완료되었는지 확인하세요.
• parallel에서 실행된 작업에서 artifact를 다운로드할 수 없습니다.
• project, job, ref에서 CI/CD 변수 지원.

관련 주제:

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

needs:pipeline:job

자식 파이프라인은 부모 파이프라인 또는 동일한 부모-자식 파이프라인 계층구조의 다른 자식 파이프라인에서 작업에서 artifact를 다운로드할 수 있습니다.

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

가능한 입력값:

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

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 작업은 일부 artifact를 만듭니다. child-pipeline 작업은 자식 파이프라인을 트리거하고 PARENT_PIPELINE_ID 변수를 새 PARENT_PIPELINE_ID 변수로 자식 파이프라인에 전달합니다. 자식 파이프라인은 needs:pipeline에서 해당 변수를 사용하여 부모 파이프라인에서 artifact를 다운로드할 수 있습니다.

추가 세부 정보:

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

needs:optional

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

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

• needs 항목에 optional: true가 있고 필요한 작업이 파이프라인에 있는 경우, 작업은 시작하기 전에 해당 작업이 완료될 때까지 대기합니다.
• 필요한 작업이 없는 경우, 다른 모든 요구 사항을 충족한 경우 작업을 시작할 수 있습니다.
• 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

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

다음을 해야 합니다:

• public이 기본값인 컨텐츠 디렉터리의 경로를 사용하여 artifacts를 정의해야 합니다.
• 다른 컨텐츠 디렉터리를 사용하려면 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 작업의 일부로만 사용할 수 있습니다.

가능한 입력값: 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이라는 플래그로 실험으로 소개되었으며, 기본적으로 비활성화되어 있습니다.
• GitLab 17.4에서 GitLab.com, Self-managed, GitLab Dedicated에서 활성화됨.

평행 배포를 위한 경로 접두어를 구성하는 데 pages.path_prefix를 사용합니다.

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

가능한 입력값: 문자열, CI/CD 변수, 또는 이들의 조합. 주어진 값은 소문자로 변환되고, 63바이트로 줄여지며, 알파벳 및 숫자 이외의 문자는 하이픈으로 대체됩니다. 선행 및 후행 하이픈은 허용되지 않습니다.

pages.path_prefix의 예시:

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

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

pages:pages.expire_in

• GitLab 17.4에서 소개되었습니다.

expire_in을 사용하여 만료되기 전에 배포가 얼마나 오랫동안 사용 가능한지를 지정합니다. 배포가 만료되면 10분마다 실행되는 cron 작업에 의해 비활성화됩니다.

추가 배포는 기본적으로 만료됩니다. 만료되지 않도록 하려면 값을 ‘never’로 설정합니다.

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

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

• '42'
• 42 seconds
• 3 mins 4 sec
• 2 hrs 20 min
• 2h20min
• 6 mos 1 day
• 47 yrs 6 mos and 4d
• 3 weeks and 2 days
• never

pages:pages.expire_in의 예시:

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

parallel

• GitLab 15.9에서, parallel의 최대 값이 50에서 200으로 증가되었습니다.

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

여러 개의 러너가 존재해야 하거나 단일 러너가 병렬로 여러 작업을 실행하도록 설정되어야 합니다.

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

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

가능한 입력값:

• 1에서 200 사이의 숫자 값.

parallel의 예시:

test:
  script: rspec
  parallel: 5

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

추가 정보:

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

관련 주제:

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

parallel:matrix

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

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

여러 개의 러너가 존재해야 하거나 단일 러너가 병렬로 여러 작업을 실행하도록 설정되어야 합니다.

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

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

• 변수 이름은 숫자, 문자 및 밑줄(_)만 사용할 수 있습니다.
• 값은 문자열 또는 문자열 배열이어야 합니다.
• 순열의 수가 200을 넘을 수 없습니다.

parallel:matrix의 예시:

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

이 예시에서는 PROVIDER 및 STACK의 각 값이 다른 10개의 병렬 deploystacks 작업을 생성합니다.

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

추가 정보:

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

• 동일한 변수 값으로 여러 개의 행렬 구성을 만들 수 없습니다. 작업 이름은 변수 이름이 아닌 변수 값에서 생성되므로 동일한 값을 가진 행렬 항목은 동일한 작업 이름을 생성하여 덮어쓸 수 있습니다.

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

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

  • !reference 태그를 parallel:matrix와 함께 사용할 때 알려진 문제가 있습니다.

관련 주제:

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

릴리스

릴리스를 생성하려면 릴리스를 사용하세요.

릴리스 작업은 릴리스-cli에 액세스해야 합니다. 이는 $PATH에 있어아 합니다.

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

Shell executor나 유사한 것을 사용하는 경우, 릴리스-cli를 실행하는 서버에 install release-cli를 설치할 수 있습니다.

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

가능한 입력값: 릴리스 하위 키:

• tag_name
• tag_message (옵션)
• name (옵션)
• description
• ref (옵션)
• milestones (옵션)
• released_at (옵션)
• assets:links (옵션)

릴리스 키워드 예시:

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

이 예시는 다음을 실행합니다:

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

추가 정보:

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

  script:
    - echo "릴리스 작업"
  

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

• 릴리스 섹션은 script 키워드 후에 실행되며, after_script 전에 실행됩니다.
• 릴리스는 작업의 주 스크립트가 성공한 경우에만 생성됩니다.
• 이미 있는 릴리스의 경우 업데이트되지 않으며, 릴리스 키워드가 있는 작업은 실패합니다.

관련 주제:

• CI/CD example of the release keyword.
• 한 번에 여러 릴리스 생성하기.
• 사용자 정의 SSL CA 인증서 사용하기.

릴리스:tag_name

필수. 릴리스의 Git 태그입니다.

프로젝트에 해당 태그가 아직 없는 경우, 릴리스와 동시에 생성됩니다. 새로운 태그는 파이프라인과 관련된 SHA를 사용합니다.

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

가능한 입력값:

• 태그 이름.

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

릴리스:tag_name 예시:

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

• tag_name으로 $CI_COMMIT_TAG CI/CD 변수를 사용합니다.
• rules:if를 사용하여 새 태그에 대해 작업을 구성합니다.

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

릴리스를 생성하고 동시에 새 태그를 만들려면, 여러분의 rules 는 작업을 새 태그에 대해서만 실행되도록 구성하면 안됩니다. 의미있는 버전 예시:

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

릴리스:tag_message

• GitLab 15.3에서 도입. 릴리스-cli v0.12.0 이상에서 지원됩니다.

새로운 태그가 없는 경우, 새로 생성된 태그는 tag_message로 지정된 메시지로 주석이 달립니다. 생략된 경우, 가벼운 태그가 생성됩니다.

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

가능한 입력값:

• 텍스트 문자열.

릴리스:tag_message 예시:

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

릴리스:name

릴리스 이름입니다. 생략된 경우, 릴리스: tag_name의 값을 사용합니다.

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

가능한 입력값:

• 텍스트 문자열.

릴리스:name 예시:

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

릴리스:description

릴리스의 긴 설명입니다.

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

가능한 입력값:

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

릴리스:description 예시:

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

추가 정보:

• description은 릴리스-cli를 실행하는 셸에 의해 평가됩니다. CI/CD 변수를 정의하는 데에 변수를 사용할 수 있지만, 특정 셸은 다른 구문을 변수에 대한 참조를 위해 사용할 수 있습니다. 마찬가지로, 특정 셸은 특수 문자를 이스케이핑해야 할 수도 있습니다. 예를 들어, 백틱 (`)은 백슬래시(\)로 이스케이핑해야 할 수도 있습니다.

release:ref

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

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

가능한 입력:

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

release:milestones

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

release:released_at

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

가능한 입력:

• ISO 8601 형식으로 표현된 따옴표로 둘러싸인 날짜.

release:released_at의 예시:

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

추가 세부 정보:

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

release:assets:links

릴리스에 자산 링크를 포함시키려면 release:assets:links를 사용합니다.

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

release:assets:links의 예시:

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

resource_group

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

예를 들어, 동일한 자원 그룹에 속하는 여러 작업이 동시에 대기 중인 경우, 작업 중 하나만 시작됩니다. 다른 작업은 resource_group이 사용 가능해질 때까지 대기합니다.

자원 그룹은 다른 프로그래밍 언어에서의 세마포어와 유사한 동작을 합니다.

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

환경별로 여러 자원 그룹을 정의할 수 있습니다. 예를 들어, 물리적 장치로 배포할 때 여러 물리적 장치를 가질 수 있습니다. 각 장치는 배포할 수 있지만 특정 시점에서 장치 당 한 번의 배포만 발생합니다.

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

가능한 입력:

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

resource_group의 예시:

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

이 예시에서 deploy-to-production 작업은 두 개의 별개 파이프라인에서 한 번에 실행되지 않습니다. 결과적으로 병행 배포가 생산 환경에 대해 발생하지 않도록 할 수 있습니다.

관련 주제:

• 상호 프로젝트/부모-자식 파이프라인 간에 파이프라인 수준의 동시성 제어.

retry

작업이 실패할 경우 작업을 몇 번 다시 시도할지 구성하기 위해 retry를 사용합니다. 정의되지 않으면 기본적으로 0으로 설정되어 작업은 다시 시도하지 않습니다.

작업이 실패할 경우, 작업은 성공할 때까지 또는 최대 다시 시도 횟수에 도달할 때까지 최대 두 번 더 처리됩니다.

기본적으로 모든 종류의 실패로 인해 작업이 다시 시도됩니다. 실패 유형을 선택하려면 retry:when 또는 retry:exit_codes를 사용하세요.

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

가능한 입력:

• 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일 때 또는 runner 시스템 실패가 있었을 때 최대 2번까지 다시 시도됩니다.

retry:when

retry:when을 retry:max와 함께 사용하여 특정 실패 케이스에 대해 작업을 다시 시도합니다. retry:max는 retry와 유사한 최대 다시 시도 횟수이며 0, 1, 또는 2가 될 수 있습니다.

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

가능한 입력:

• 단일 실패 유형 또는 하나 이상의 실패 유형으로 이루어진 배열:

• always: 모든 실패에 대해 다시 시도(기본값).
• unknown_failure: 실패 원인이 알 수 없을 때 다시 시도.
• script_failure: 다음과 같은 경우 다시 시도:
  • 스크립트 실패.
  • runner가 Docker 이미지를 끌어오지 못했을 때. docker, docker+machine, kubernetes executors의 경우.
• api_failure: API 실패 시 다시 시도.
• stuck_or_timeout_failure: 작업이 정체되었거나 시간 초과했을 때 다시 시도.
• runner_system_failure: runner 시스템 실패 시 다시 시도 (예: 작업 설정 실패).
• runner_unsupported: runner가 지원되지 않을 때 다시 시도.
• stale_schedule: 지연된 작업을 실행할 수 없을 때 다시 시도.
• job_execution_timeout: 작업에 설정된 최대 실행 시간을 초과했을 때 다시 시도합니다.
• archived_failure: 작업이 보관되어 실행할 수 없을 때 다시 시도.
• unmet_prerequisites: 작업이 선행 작업을 완료하지 못했을 때 다시 시도.
• scheduler_failure: 스케줄러가 작업을 runner에 할당하지 못했을 때 다시 시도.
• data_integrity_failure: 알 수 없는 작업 문제가 있을 때 다시 시도.

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

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

runner 시스템 실패가 아닌 다른 실패가 발생할 경우, 작업은 다시 시도되지 않습니다.

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 및 자체 관리형에서 활성화됨.

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

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

가능한 입력:

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

retry:exit_codes 예시:

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

test_job_2:
  script:
    - echo "종료 코드 137로 이어지는 스크립트 실행. 이 작업은 재시도될 것입니다."
    - exit 137
  retry:
    max: 1
    exit_codes:
      - 255
      - 137

관련 주제:

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

rules

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

파이프라인 생성 시 규칙이 작성되며, 순서대로 평가됩니다. 일치하는 경우 더 이상의 규칙을 확인하지 않고 작업이 설정에 따라 파이프라인에 포함되거나 제외됩니다. 일치하는 규칙이 없으면 작업이 파이프라인에 추가되지 않습니다.

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

• if
• changes
• exists
• when

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

• allow_failure
• needs
• variables
• interruptible

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

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

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

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

• 규칙이 일치하지 않는 경우.
• 규칙이 일치하고 when: never로 설정된 경우.

추가 예시는 규칙을 사용하여 작업을 실행시키는 지정하기를 참고하세요.

rules:if

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

• if 문이 참이면 작업을 파이프라인에 추가합니다.
• if 문이 참이지만 when: never로 결합된 경우에는 작업을 파이프라인에 추가하지 않습니다.
• if 문이 거짓인 경우 다음 rules 항목(있는 경우)을 확인합니다.

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

• CI/CD 변수 또는 사전 정의된 CI/CD 변수의 값에 기반하여, 일부 예외 사항을 따라.
• rules 실행 흐름을 따라 순서대로.

키워드 유형: 작업별 및 파이프라인별. 작업 동작을 구성하기 위해 작업의 일부로 사용하거나 workflow로 파이프라인 동작을 구성하기 위해 사용할 수 있습니다.

가능한 입력:

• CI/CD 변수 표현식.

rules:if 예시:

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

추가 세부 정보:

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

관련 주제:

• rules를 위한 일반적인 if 표현식들: rules에 있는 일반적인 if 표현식들.
• 중복 파이프라인을 피하세요.
• 병합 요청 파이프라인을 실행하기 위해 rules를 사용하세요.

rules:changes

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

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

compare_to를 사용하지 않는 경우 브랜치 파이프라인 또는 병합 요청 파이프라인과 함께 rules: changes를 사용해야 합니다. 그러나 새 브랜치를 만들 때 rules: changes는 여전히 true로 평가됩니다. 다음과 같이:

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

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

가능한 입력:

• 파일 경로를 포함하는 배열. 파일 경로에는 CI/CD variables를 포함할 수 있습니다.
• 원시 경로:
  • 단일 디렉토리에 대한 와일드카드 경로, 예: path/to/directory/*.
  • 디렉토리 및 해당 하위 디렉토리에 대한 와일드카드 경로, 예: path/to/directory/**/*.
• 동일한 확장자 또는 여러 확장자가 있는 모든 파일에 대한 와일드카드 glob 경로, 예: *.md 또는 path/to/directory/*.{rb,py,sh}.
• 루트 디렉토리 또는 모든 디렉토리에있는 파일에 대한 와일드카드 경로를 이중 인용부호로 묶어줍니다. 예: "*.json" 또는 "**/*.json".

rules:changes 예시:

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

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

이 예시에서:

• 파이프라인이 병합 요청 파이프라인인 경우 Dockerfile 및 $DOCKERFILES_DIR/**/*을 변경 사항으로 확인합니다.
• Dockerfile에 변경 사항이 있는 경우, 작업을 수동으로 파이프라인에 추가하고 작업이 트리거되지 않아도 파이프라인이 계속 실행됩니다(allow_failure: true).
• $DOCKERFILES_DIR/**/*의 파일에 변경 사항이 있는 경우, 작업을 파이프라인에 추가합니다.
• 나열된 파일에 변경 사항이 없는 경우, 두 작업 중 어느 하나도 파이프라인에 추가하지 않습니다(when: never와 동일).

추가 정보:

• 글로브 패턴은 루비의 File.fnmatch 및 flags File::FNM_PATHNAME | File::FNM_DOTMATCH | File::FNM_EXTGLOB로 해석됩니다.
• rules:changes 섹션 당 최대 50개의 패턴 또는 파일 경로를 정의 할 수 있습니다.
• 변경 사항이 있을 경우 (OR 연산) 해당되는 파일 중 하나라도 변경되면 changes는 true로 해석됩니다.
• 자세한 예시에 대해서는 rules로 작업을 실행할 때 지정`을 확인하십시오.
• 변수 및 경로 모두에 $ 문자를 사용할 수 있습니다. 예를 들어, $VAR 변수가 존재하는 경우 해당 값을 사용합니다. 변수가 존재하지 않으면 $를 경로의 일부로 해석합니다.
• changes와 중첩 변수를 사용할 수 없습니다. 자세한 내용은 이슈 425803을 참조하십시오.

관련 주제:

• rules로 작업을 실행할 때 지정 시에 rules: changes를 사용하여 작업이 예상치 못하게 실행되는 경우 문제 해결.

rules:changes:paths

• GitLab 15.2에서 도입.

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

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

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

가능한 입력:

• 위의 rules:changes의 가능한 입력 참조

rules:changes:paths 예시:

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

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

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

rules:changes:compare_to

• GitLab 15.3에서 이슈 등록. 기본으로 활성화된 ci_rules_changes_compare라는 플래그와 함께 도입됨.
• GitLab 15.5에서 일반 사용 가능해짐. ci_rules_changes_compare 플래그 제거.
• GitLab 17.2에서 CI/CD 변수 지원 도입.

rules:changes:compare_to를 사용하여 rules:changes:paths에 지정된 파일의 변경을 위해 비교할 ref를 지정할 수 있습니다.

키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있습니다. 반드시 rules:changes:paths와 함께 사용되어야 합니다.

가능한 입력:

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

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

rules:changes:compare_to 예시:

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

이 예시에서 Dockerfile이 refs/heads/branch1에 대해 변경되었을 때만 docker build 작업이 포함됩니다. 또한 파이프라인 소스가 병합 요청 이벤트인 경우입니다.

추가 정보:

• 병합된 결과 파이프라인에서 compare_to를 사용하면 예상치 못한 결과가 발생할 수 있습니다. 이는 비교 기준이 GitLab이 생성하는 내부 커밋인 경우에 해당됩니다.

관련 주제:

• 브랜치가 비어 있을 때 작업을 건너뛰기 위해 rules:changes:compare_to를 사용할 수 있습니다.

rules:exists

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

exists를 사용하여 저장소에 특정 파일이 있는 경우 작업을 실행합니다.

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

가능한 입력:

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

rules:exists 예시:

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

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

이 예시에서:

• job1은 저장소의 루트 디렉토리에 Dockerfile이 있는 경우 실행됩니다.
• job2은 저장소 어디에든 Dockerfile이 있는 경우 실행됩니다.

추가 세부 정보:

• rules:exists와 함께 사용되는 CI/CD 변수에는 일부 제한 사항이 있습니다:
  • exists로 중첩된 변수를 사용할 수 없습니다. 자세한 내용은 issue 411344을 참조하십시오.
  • 경우에 따라 exists와 함께 CI/CD 변수에서/ 또는 ./를 사용할 수 없습니다. 자세한 내용은 issue 386595를 참조하십시오.
• Glob 패턴은 Ruby의 File.fnmatch과 flags(File::FNM_PATHNAME | File::FNM_DOTMATCH | File::FNM_EXTGLOB)로 해석됩니다.
• 성능상의 이유로 GitLab은 exists 패턴이나 파일 경로에 대해 최대 10,000회의 확인을 수행합니다. 10,000번째 확인 이후에는 패턴화된 glob은 항상 일치한다고 가정합니다. 즉, 프로젝트에 10,000개 이상의 파일이 있는 경우 또는 10,000개 미만의 파일이지만 exists 규칙이 10,000회 이상 확인되는 경우 exists 규칙은 항상 일치한다고 가정합니다.
  • 패턴화된 glob이 여러 개인 경우 한계는 10,000을 glob 수로 나눈 값입니다. 예를들어, 4개의 패턴화된 glob이 있는 규칙의 파일 한도는 2500입니다.
• rules:exists 섹션 당 최대 50개의 패턴이나 파일 경로를 정의할 수 있습니다.
• exists는 나열된 파일 중 하나라도 찾으면 true로 해석됩니다(OR 연산).
• Job 레벨 rules:exists의 경우 GitLab은 파이프라인을 실행하는 프로젝트와 ref에서 파일을 검색합니다. include와 rules:exists를 사용하는 경우 GitLab은 include 섹션을 포함하는 파일의 프로젝트와 ref에서 파일을 검색합니다. include 섹션을 포함하는 프로젝트가:
  • 중첩된 includes를 사용할 때.
  • 컴플라이언스 파이프라인을 사용하는 경우.
• rules:exists는 아티팩트의 존재를 검색할 수 없습니다. 왜냐하면 rules 평가는 작업을 실행하기 전에 진행되고 아티팩트가 가져와지기 때문입니다.

rules:exists:paths

• GitLab 16.11에 ci_support_rules_exists_paths_and_project라는 플래그로 도입되었습니다. 기본적으로 비활성화되어 있습니다.
• GitLab 17.0에서 일반적으로 사용 가능해졌습니다. ci_support_rules_exists_paths_and_project 플래그가 제거되었습니다.

rules:exists:paths는 rules:exists를 사용하는 것과 동일합니다.

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

가능한 입력:

• 파일 경로의 배열.

rules:exists:paths 예시:

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

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

이 예시에서 두 Job은 동일한 동작을 합니다.

추가 세부 정보:

• 경우에 따라 exists와 함께 CI/CD 변수에서/ 또는 ./를 사용할 수 없습니다. 자세한 내용은 issue 386595를 참조하십시오.

rules:exists:project

• GitLab 16.11에 ci_support_rules_exists_paths_and_project라는 플래그로 도입되었습니다. 기본적으로 비활성화되어 있습니다.
• GitLab 17.0에서 일반적으로 사용 가능해졌습니다. ci_support_rules_exists_paths_and_project 플래그가 제거되었습니다.

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

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

가능한 입력:

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

rules:exists:project 예시:

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

이 예시에서 docker build 작업은 v1.0.0로 태그가 지정된 커밋에서 my-group/my-project 프로젝트에 Dockerfile이 있는 경우에만 포함됩니다.

rules:when

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

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

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

가능한 입력값:

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

rules:when의 예시:

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

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

• 기본 브랜치에 대해 when: on_success으로 추가됩니다. 이는 when이 정의되지 않은 경우의 기본 동작입니다.
• 기능 브랜치에 지연 작업으로 추가됩니다.
• 다른 모든 경우에는 수동 작업으로 추가됩니다.

추가 세부 정보:

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

rules:allow_failure

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

수동 작업에서도 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