CI/CD YAML 구문 참조

PreviousCI/CD 컴포넌트 NextCI/CD Notifications

Last updated 1 year ago

CI/CD YAML 구문 참조

include:template

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

가능한 입력:

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

추가 정보:

`after_script`

가능한 입력값: 아래를 포함하는 배열:

한 줄 명령어.

after_script의 예시:

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

추가 정보:

after_script에 지정한 스크립트는 before_script 또는 script 명령에서 수행한 변경사항과 독립된 새 쉘에서 실행됩니다. 결과적으로 다음과 같은 특징을 가지게 됩니다:

before_script 또는 script 스크립트에서 수행한 변경사항의 접근 권한이 없습니다.
- script 스크립트에서 내보낸 명령 별칭 및 변수.
- before_script 또는 script 스크립트에서 설치한 소프트웨어와 같은 작업 영역 외의 변경사항 (런너 실행자에 따라 달라집니다).
작업의 종료 코드에 영향을 주지 않습니다. script 섹션이 성공하고 after_script 명령이 타임아웃되거나 실패하더라도 작업은 코드 0 (작업 성공)으로 종료됩니다.

관련 주제:

`before_script`

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

Single line commands.

before_script 예시:

job:
  before_script:
    - echo "스크립트 명령어 이전에 이 명령어를 실행합니다."
  script:
    - echo "이 명령어는 작업의 'before_script' 명령어 후에 실행됩니다."

추가 정보:

관련 주제:

[default와 함께 before_script 사용](script.md#set-a-default-before_script-or-after_script-for-all-jobs)하여 모든 작업의 script` 명령어 전에 실행되어야 하는 기본 명령어 배열을 정의합니다.

`retry`

retry를 사용하여 작업이 실패할 경우 재시도되는 횟수를 구성하세요. 정의되지 않으면 기본값은 0이며 작업은 재시도되지 않습니다.

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

가능한 입력값:

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

retry의 예시:

test:
  script: rspec
  retry: 2

test_advanced:
  script:
    - echo "종료 코드가 137인 스크립트 실행."
    - exit 137
  retry:
    max: 2
    when: runner_system_failure
    exit_codes: 137

test_advanced는 종료 코드가 137이거나 실행중인 시스템에 장애가 발생할 경우 최대 2회까지 재시도됩니다.

retry:when

가능한 입력값:

단일 실패 유형 또는 하나 이상의 실패 유형 배열:
always: 모든 실패시 재시도 (기본값).
unknown_failure: 실패 이유가 알려지지 않았을 때 재시도.
script_failure: 다음 경우에 재시도:
- 스크립트 실행 실패시
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

가능한 입력값:

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

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는 파이프라인이 생성될 때 평가되며, 평가는 순서대로 진행됩니다. 일치하는 항목이 발견되면, 작업은 구성에 따라 파이프라인에 포함되거나 제외됩니다.

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

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

if
changes
exists
allow_failure
variables
when

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

if, changes, 또는 exists 규칙이 일치하고, 또한 when: on_success (기본값), when: delayed, 또는 when: always를 갖는 경우.
특정 when: on_success, when: delayed, 또는 when: always에 도달한 경우.

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

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

rules:if

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

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

가능한 입력:

rules:if의 예시:

job:
  script: echo "안녕, 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이 없는 경우, 규칙은 작업에 대해 정의된 기본값이 on_success인 when을 사용합니다.
GitLab 14.5 이전에는 규칙 당 when을 한 번 정의하거나 작업 수준에서 한 번 정의할 수 있었습니다. 이는 모든 규칙에 적용되는 것입니다. 작업 수준의 when과 규칙 내의 when을 혼합할 수 없습니다.

관련 주제:

rules:changes

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

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

가능한 입력:

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

파이프라인이 병합 요청 파이프라인인 경우 Dockerfile을 변경 사항을 확인하십시오.
Dockerfile에 변경 사항이 있으면 작업을 수동 작업으로 파이프라인에 추가하고, 작업이 트리거되지 않아도 파이프라인이 계속 실행됩니다 (allow_failure: true).
rules: changes 섹션 당 최대 50개의 패턴 또는 파일 경로를 정의할 수 있습니다.
Dockerfile에 변경 사항이 없으면 어떤 파이프라인에도 작업을 추가하지 마십시오 (when: never와 동일함).

rules:changes:paths

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

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

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

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

키워드 유형: 작업 키워드. 작업의 일부로만 사용할 수 있으며 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을 기준으로 변경되었고 파이프라인 소스가 병합 요청 이벤트인 경우에만 포함됩니다.

rules:exists

exists를 사용하여 저장소에 특정 파일이 존재할 때 작업을 실행합니다.

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

가능한 입력:

rules:exists의 예시:

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

Dockerfile이 저장소 어디에 있든, job은 실행됩니다.

추가 세부 정보:

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

rules:allow_failure

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

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

가능한 입력:

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

rules:allow_failure의 예시:

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

규칙이 일치하는 경우, 작업은 allow_failure: true를 가진 수동 작업입니다.

추가 세부 정보:

rules:needs

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

가능한 입력:

문자열로 된 작업 이름의 배열.
작업 이름과 선택적으로 추가 속성이 포함된 해시.
특정 조건을 충족하는 경우 작업 needs를 없음으로 설정하려면 빈 배열([])을 사용합니다.

rules:needs 예시:

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

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

specs:
  stage: test
  needs: ['build-dev']
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      needs: ['build-prod']
    - when: on_success # 다른 경우에도 작업 실행
  script: echo "기본적으로 개발 사양 실행 또는 기본 브랜치일 때 프로덕션 사양 실행..."

이 예시에서:

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

추가 세부 정보:

rules:variables

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

가능한 입력:

VARIABLE-NAME: 값을 형식으로 된 변수 해시.

rules:variables 예시:

job:
  variables:
    DEPLOY_VARIABLE: "default-deploy"
  rules:
    - if: $CI_COMMIT_REF_NAME == $CI_DEFAULT_BRANCH
      variables:                              # 작업 수준에서 정의된 DEPLOY_VARIABLE을 재정의
        DEPLOY_VARIABLE: "deploy-production"  #합니다.
    - if: $CI_COMMIT_REF_NAME =~ /feature/
      variables:
        IS_A_FEATURE: "true"                  # 새 변수를 정의합니다.
  script:
    - echo "$DEPLOY_VARIABLE을(를) 인자로 사용하여 스크립트 실행"
    - "$IS_A_FEATURE가 있는 경우 다른 스크립트 실행"

rules:interruptible

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

가능한 입력:

true 또는 false.

rules:interruptible 예시:

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

추가 세부 정보:

stage: .pre

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

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

stage: .pre 예시:

stages:
  - build
  - test

job1:
  stage: build
  script:
    - echo "이 작업은 빌드 단계에서 실행됩니다."

first-job:
  stage: .pre
  script:
    - echo ".pre 단계에서 이 작업이 실행됩니다. 다른 모든 단계보다 먼저 실행됩니다."

job2:
  stage: test
  script:
    - echo "이 작업은 테스트 단계에서 실행됩니다."

stage: .post

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

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

stage: .post 예시:

stages:
  - build
  - test

job1:
  stage: build
  script:
    - echo "이 작업은 빌드 단계에서 실행됩니다."

last-job:
  stage: .post
  script:
    - echo "이 작업은 .post 단계에서 실행됩니다. 다른 모든 단계보다 나중에 실행됩니다."

job2:
  stage: test
  script:
    - echo "이 작업은 테스트 단계에서 실행됩니다."

추가 세부 정보:

관련 주제:

추가 정보:

build_job이 실패할 때만 cleanup_build_job을 실행합니다.
어떤 경우에도 cleanup_job을 파이프라인의 마지막 단계로 실행합니다.
GitLab UI에서 수동으로 실행할 때 deploy_job을 실행합니다.

이 예시에서 스크립트는 다음을 실행합니다:

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

build_job:
  stage: build
  script:
    - make build

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

test_job:
  stage: test
  script:
    - make test

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

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

when 예시:

on_success (기본값): 이전 단계의 작업 중 실패한 작업이 없을 때 또는 allow_failure: true가 있는 경우에만 작업을 실행합니다.
on_failure: 이전 단계에서 적어도 한 작업이 실패할 때 작업을 실행합니다. 이전 단계의 allow_failure: true가 있는 작업은 항상 성공으로 간주됩니다.
never: 이전 단계의 상태에 관계없이 작업을 실행하지 않습니다. rules 섹션 또는 workflow:rules에서만 사용할 수 있습니다.
always: 이전 단계의 상태에 관계없이 작업을 실행합니다. workflow:rules에서도 사용할 수 있습니다.

가능한 입력:

작업이 실행되는 조건을 구성하기 위해 when을 사용합니다. 작업 내에서 정의되지 않은 경우 기본값은 when: on_success입니다.

`when`

추가 정보:

VAR2의 결과는 value2 value1입니다.
VAR3의 결과는 value3 $VAR1입니다.

variables:
  VAR1: value1
  VAR2: value2 $VAR1
  VAR3:
    value: value3 $VAR1
    expand: false

변수:확장 예시:

true (기본값): 변수는 확장 가능합니다.
false: 변수는 확장할 수 없습니다.

가능한 입력:

키워드 유형: 글로벌 및 작업 키워드. 전역 수준과 작업 수준에서 사용할 수 있습니다.

expand 키워드를 사용하여 변수를 확장 가능하게 또는 그렇지 않게 구성합니다.

변수:확장

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

variables:options의 예시:

문자열 배열.

가능한 입력:

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

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

variables:value와 함께 사용해야 하며, value에 정의된 문자열은 다음을 만족해야 합니다:

variables:options

추가 세부정보:

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

variables:value의 예시:

문자열.

가능한 입력:

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

variables:value

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

추가 세부정보:

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

variables:description의 예시:

문자열.

가능한 입력:

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

variables:description

관련 주제:

추가 세부정보:

variables:
  DEPLOY_SITE: "https://example.com/"

deploy_job:
  stage: deploy
  script:
    - deploy-script --url $DEPLOY_SITE --path "/"
  environment: production

deploy_review_job:
  stage: deploy
  variables:
    REVIEW_PATH: "/review"
  script:
    - deploy-review-script --url $DEPLOY_SITE --path $REVIEW_PATH
  environment: production

variables의 예시:

이름은 숫자, 문자 및 밑줄(_)만 사용할 수 있습니다. 일부 셸에서는 첫 번째 문자가 문자여야 합니다.
값은 문자열이어야 합니다.

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

키워드 유형: 글로벌 및 작업 키워드. 글로벌 수준과 작업 수준에서 사용할 수 있습니다.

`variables`

추가 세부 정보:

variables: # 각 작업에 대한 기본 변수
  VAR: value

# 기본 동작:
# - VAR이 자식에게 전달됨
# - MYVAR는 자식에게 전달되지 않음
child1:
  trigger:
    include: .child-pipeline.yml

# 파이프라인 변수 전달:
# - VAR이 자식에게 전달됨
# - MYVAR는 자식에게 전달됨
child2:
  trigger:
    include: .child-pipeline.yml
    forward:
      pipeline_variables: true

# YAML 변수를 전달하지 않음:
# - VAR가 자식에게 전달되지 않음
# - MYVAR가 자식에게 전달되지 않음
child3:
  trigger:
    include: .child-pipeline.yml
    forward:
      yaml_variables: false

trigger:forward의 예시:

yaml_variables: true (기본값) 또는 false. true인 경우, 트리거 작업에 정의된 변수가 다운스트림 파이프라인에 전달됩니다.

가능한 입력값:

trigger:forward

추가 세부 정보:

이 예시에서, 다음 스테이지의 작업들은 트리거된 파이프라인이 성공적으로 완료될 때까지 기다립니다.

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

trigger:strategy의 예시:

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

기본 동작과 다른 점은 trigger 작업이 완료되자마자 성공으로 표시되는 것이 아니라는 것입니다.

trigger:strategy를 사용하여 trigger 작업이 다운스트림 파이프라인이 완료될 때까지 성공으로 표시되기 전까지 기다리도록 강제할 수 있습니다.

trigger:strategy

관련 주제:

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

다른 브랜치용 trigger:project의 예시:

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

trigger:project의 예시:

가능한 입력값:

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

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

trigger:project

관련 주제:

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

trigger:include의 예시:

하위 파이프라인 구성 파일의 경로.

가능한 입력값:

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

trigger:include

`when`

작업이 실행되는 조건을 구성하기 위해 when을 사용합니다. 작업 내에서 정의되지 않은 경우 기본값은 when: on_success입니다.

가능한 입력:

on_success (기본값): 이전 단계의 작업 중 실패한 작업이 없을 때 또는 allow_failure: true가 있는 경우에만 작업을 실행합니다.
on_failure: 이전 단계에서 적어도 한 작업이 실패할 때 작업을 실행합니다. 이전 단계의 allow_failure: true가 있는 작업은 항상 성공으로 간주됩니다.
never: 이전 단계의 상태에 관계없이 작업을 실행하지 않습니다. rules 섹션 또는 workflow:rules에서만 사용할 수 있습니다.
always: 이전 단계의 상태에 관계없이 작업을 실행합니다. workflow:rules에서도 사용할 수 있습니다.

when 예시:

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

build_job:
  stage: build
  script:
    - make build

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

test_job:
  stage: test
  script:
    - make test

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

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

이 예시에서 스크립트는 다음을 실행합니다:

build_job이 실패할 때만 cleanup_build_job을 실행합니다.
어떤 경우에도 cleanup_job을 파이프라인의 마지막 단계로 실행합니다.
GitLab UI에서 수동으로 실행할 때 deploy_job을 실행합니다.

추가 정보:

Last updated 1 year ago