rules로 작업 실행 시기 지정
only 및 except로 작업 실행 시기 지정
수동으로 실행해야 하는 작업 만들기
지연 후 작업 실행
대규모 작업 병렬화
여러 병렬화된 작업을 needs로 지정하기
미리 정의된 CI/CD 변수를 사용하여 특정 파이프라인 유형에서 작업 실행
정규 표현식
- only / except 정규 표현식 구문
CI/CD 변수 표현식

작업 실행 시기 선택

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

새로운 파이프라인이 시작되면 GitLab은 해당 파이프라인에서 실행해야 하는 작업을 확인하기 위해 파이프라인 구성을 확인합니다. 변수의 상태 또는 파이프라인 유형과 같은 요소에 따라 작업을 실행하도록 구성할 수 있습니다.

작업을 특정 파이프라인에 포함하거나 제외하려면 rules을 사용하세요.

needs를 사용하여 이전 작업이 실행을 마치자마자 해당 작업이 실행되도록 구성하세요.

`rules`로 작업 실행 시기 지정

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

rules을 사용하여 파이프라인에서 작업을 포함하거나 제외하세요.

규칙은 첫 번째 일치하는 항목을 찾을 때까지 차례대로 평가됩니다. 일치하는 항목을 찾으면 구성에 따라 작업이 파이프라인에 포함되거나 제외됩니다. 자세한 내용은 rules 참조를 확인하세요.

향후 키워드 개선 사항은 규칙을 개선하기 위한 epic에서 논의 중이며 누구나 제안이나 요청을 추가할 수 있습니다.

`rules` 예

다음 예시는 if를 사용하여 작업이 특정 두 경우에만 실행되도록 정의합니다:

job:
  script: echo "안녕, Rules!"
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      when: manual
      allow_failure: true
    - if: $CI_PIPELINE_SOURCE == "schedule"

이 파이프라인이 병합 요청을 위한 것이라면, 첫 번째 규칙이 일치하고 작업은 병합 요청 파이프라인에 다음의 속성과 함께 추가됩니다:
- when: manual (수동 작업)
- allow_failure: true (수동 작업이 실행되지 않아도 파이프라인은 계속 실행됨)
만약 이 파이프라인이 병합 요청을 위한 것이 아니라면, 첫 번째 규칙은 일치하지 않고 두 번째 규칙이 평가됩니다.
이 파이프라인이 예약된 파이프라인이라면, 두 번째 규칙이 일치하고 작업은 예약된 파이프라인에 추가됩니다. 속성이 정의되지 않았으므로 다음과 같이 추가됩니다:
- when: on_success (기본값)
- allow_failure: false (기본값)
모든 다른 경우에는 규칙이 일치하지 않으므로 작업은 다른 파이프라인에는 추가되지 않습니다.

대안으로, 일부 경우에 작업을 제외하고 모든 다른 경우에 실행할 수 있는 규칙을 정의할 수 있습니다:

job:
  script: echo "안녕, Rules!"
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      when: never
    - if: $CI_PIPELINE_SOURCE == "schedule"
      when: never
    - when: on_success

이 파이프라인이 병합 요청을 위한 것이라면, 작업은 파이프라인에 추가되지 않습니다.
이 파이프라인이 예약된 파이프라인이라면, 작업은 파이프라인에 추가되지 않습니다.
모든 다른 경우에는 작업은 when: on_success로 파이프라인에 추가됩니다.

경고: when 절을 마지막 규칙으로 사용하는 경우(단, when: never를 표함하지 않는 경우), 동시에 두 개의 파이프라인이 시작될 수 있습니다. 푸시 파이프라인 및 병합 요청 파이프라인은 동일한 이벤트(오픈된 병합 요청의 소스 브랜치로의 푸시)로 트리거될 수 있습니다. 자세한 내용은 중복 파이프라인 방지를 참조하세요.

예약된 파이프라인을 위해 작업 실행

작업이 예약된 파이프라인에서만 실행되도록 구성하려면 rules 키워드를 사용하세요.

이 예시에서 make world는 예약된 파이프라인에서 실행되고, make build는 브랜치 및 태그 파이프라인에서 실행됩니다:

job:on-schedule:
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"
  script:
    - make world

job:
  rules:
    - if: $CI_PIPELINE_SOURCE == "push"
  script:
    - make build

브랜치가 비어 있는 경우 작업 건너뛰기

rules:changes:compare_to를 사용하여 브랜치가 비어 있을 때 작업을 실행하지 않고 CI/CD 리소스를 저장하세요. 브랜치를 기본 브랜치와 비교하고, 브랜치에:

변경된 파일이 없는 경우, 작업을 실행하지 않습니다.
변경된 파일이 있는 경우, 작업을 실행합니다.

예를 들어, 기본 브랜치로 main이 있는 프로젝트에서:

job:
  script:
    - echo "이 작업은 빈 브랜치에만 실행됩니다"
  rules:
    - if: $CI_COMMIT_BRANCH
      changes:
        compare_to: 'refs/heads/main'
        paths:
          - '*'

이 작업을 위한 규칙은 현재 브랜치의 모든 파일과 경로(*)를 기본 브랜치 main과 비교합니다. 이 규칙이 일치하면 파일에 변경이 있고 브랜치에서 파일에 대한 변경이 있을 때만 작업이 실행됩니다.

### 복잡한 규칙

모든 `rules` 키워드를 동시에 사용할 수 있습니다. 예를 들어, `if`, `changes`, `exists`와 같은 키워드를 동시에 사용하는 규칙들을 작성할 수 있습니다. 이러한 규칙은 모든 포함된 키워드가 true로 평가될 때에만 true로 평가됩니다.

예를 들어:

```yaml
docker build:
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - if: $VAR == "string value"
      changes:  # 변경된 파일 경로 중 하나라도 이 작업을 포함하고 있으면 해당 작업을 수동으로 변경합니다.
        - Dockerfile
        - docker/scripts/*
      when: manual
      allow_failure: true

만약 Dockerfile 파일이나 /docker/scripts의 파일 중 하나라도 변경되었고 $VAR가 “string value”와 같다면, 해당 작업은 수동으로 실행되고 실패해도 됩니다.

&& 및 ||과 함께 괄호를 사용하여 더 복잡한 변수 식을 구축할 수 있습니다. GitLab 13.3에 도입됨: Introduced

job1:
  script:
    - echo This rule uses parentheses.
  rules:
    - if: ($CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH || $CI_COMMIT_BRANCH == "develop") && $MY_VARIABLE

경고: GitLab 13.3 이전에는 || 및 &&를 모두 사용하는 규칙은 예상치 못한 연산 순서로 평가될 수 있습니다.

중복 파이프라인 피하기

작업에서 rules를 사용하면 하나의 작업으로 인해 브랜치에 커밋하는 등의 단일 작업이 여러 파이프라인을 트리거할 수 있습니다. 실수로 여러 유형의 파이프라인을 명시적으로 구성할 필요는 없습니다.

중복 파이프라인을 유발할 수 있는 일부 구성에는 파이프라인 경고가 표시됩니다.

예를 들어:

job:
  script: echo "This job creates double pipelines!"
  rules:
    - if: $CUSTOM_VARIABLE == "false"
      when: never
    - when: always

이 작업은 $CUSTOM_VARIABLE이 false일 때 실행되지 않지만 모든 다른 파이프라인에서 실행되며, 이는 브랜치 푸시 및 병합 요청 파이프라인을 포함합니다. 이러한 구성으로 열린 병합 요청의 소스 브랜치에 푸시할 때마다 중복된 파이프라인이 발생합니다.

중복 파이프라인을 피하려면 다음을 할 수 있습니다:

workflow를 사용하여 실행될 수 있는 파이프라인 유형을 지정합니다.
규칙을 다시 작성하여 매우 구체적인 경우에만 작업을 실행하도록하고 최종 when 규칙을 피합니다:

job:
  script: echo "This job does NOT create double pipelines!"
  rules:
    - if: $CUSTOM_VARIABLE == "true" && $CI_PIPELINE_SOURCE == "merge_request_event"

또한 workflow: rules 없이 when: always 규칙을 사용하여 중복 파이프라인을 피할 수 있습니다.

job:
  script: echo "This job does NOT create double pipelines!"
  rules:
    - if: $CI_PIPELINE_SOURCE == "push"
      when: never
    - when: always

만약 workflow: rules 없이 푸시 (브랜치) 파이프라인 또는 병합 요청 파이프라인 중 어느 하나를 피하도록 작업 규칙을 변경한다면, 여전히 파이프라인 경고가 표시됩니다.

예를 들어, 다음은 중복 파이프라인을 유발하지는 않지만 workflow: rules 없이 권장되지는 않습니다:

job:
  script: echo "This job creates double pipelines!"
  rules:
    - if: $CI_PIPELINE_SOURCE == "push"
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

또한 같은 파이프라인 내에서 only/except 작업과 rules 작업을 혼합하면 안됩니다. 이는 YAML 오류를 유발할 수는 있지만 only/except 및 rules의 다른 기본 동작으로 문제를 유발할 수 있으므로 문제 해결이 어려울 수 있습니다.

job-with-no-rules:
  script: echo "This job runs in branch pipelines."

job-with-rules:
  script: echo "This job runs in merge request pipelines."
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

브랜치에 푸시한 모든 변경에 대해 중복 파이프라인이 실행됩니다. 하나의 브랜치 파이프라인은 하나의 작업(job-with-no-rules)을 실행하고, 하나의 병합 요청 파이프라인은 다른 작업(job-with-rules)을 실행합니다. 규칙이 없는 작업은 except: merge_requests를 기본적으로 사용하므로 job-with-no-rules은 병합 요청을 제외한 모든 경우에 실행됩니다.

`rules`를 위한 공통 `if` 절

only/except 키워드와 유사한 동작을 위해 $CI_PIPELINE_SOURCE 변수의 값을 확인할 수 있습니다.

값	설명
`api`	파이프라인 API에 의해 트리거된 파이프라인에 대해
`chat`	GitLab ChatOps 명령을 사용하여 생성된 파이프라인에 대해
`external`	GitLab 이외의 CI 서비스를 사용하는 경우
`external_pull_request_event`	GitHub에서 외부 풀 리퀘스트가 생성되거나 업데이트된 경우. 외부 풀 리퀘스트용 파이프라인 참조
`merge_request_event`	병합 요청이 생성되거나 업데이트될 때 생성된 파이프라인에 대해. 병합 요청 파이프라인, 병합 결과 파이프라인, 병합 트레인을 활성화하려면 필요
`parent_pipeline`	부모/자식 파이프라인에 의해 트리거된 파이프라인에 대해. 부모 파이프라인에서 자식 파이프라인을 트리거하기 위해 자식 파이프라인 구성에서 이 파이프라인 소스를 사용하세요
`pipeline`	API와 `CI_JOB_TOKEN`을 사용하여 생성된 멀티 프로젝트 파이프라인 또는 `trigger` 키워드를 사용하여 생성된 파이프라인에 대해
`push`	브랜치 및 태그에 대한 `git push` 이벤트에 의해 트리거된 파이프라인에 대해
`schedule`	일정 파이프라인에 대해
`trigger`	트리거 토큰을 사용하여 생성된 파이프라인에 대해
`web`	GitLab UI의 Build > Pipelines 섹션에서 프로젝트의 Run pipeline 버튼을 사용하여 생성된 파이프라인에 대해
`webide`	WebIDE를 사용하여 생성된 파이프라인에 대해

다음 예제는 schedule 파이프라인이나 (브랜치 또는 태그에 대한) push 파이프라인에서 수동으로 실행되며, 기본적으로 when: on_success 인 작업을 실행합니다. 다른 파이프라인 유형에 작업을 추가하지 않습니다.

job:
  script: echo "Hello, Rules!"
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"
      when: manual
      allow_failure: true
    - if: $CI_PIPELINE_SOURCE == "push"

다음 예제는 병합 요청 파이프라인 및 일정 파이프라인에서 when: on_success 작업으로 실행됩니다. 다른 파이프라인 유형에서는 실행되지 않습니다.

job:
  script: echo "Hello, Rules!"
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_PIPELINE_SOURCE == "schedule"

if 절에서 자주 사용되는 기타 변수:

if: $CI_COMMIT_TAG: 태그에 변경사항이 푸시된 경우
if: $CI_COMMIT_BRANCH: 어떤 브랜치에 변경사항이 푸시된 경우
if: $CI_COMMIT_BRANCH == "main": main에 변경사항이 푸시된 경우
if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH: 기본 브랜치에 변경사항이 푸시된 경우. 다른 프로젝트에서 동일한 구성을 사용하고 기본 브랜치가 다른 경우에 사용합니다.
if: $CI_COMMIT_BRANCH =~ /정규식표현/: 커밋 브랜치가 정규식과 일치하는 경우.
if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH && $CI_COMMIT_TITLE =~ /Merge branch.*/: 커밋 브랜치가 기본 브랜치이고 커밋 메시지 제목이 정규식과 일치하는 경우. 예를 들어, 병합 커밋의 기본 커밋 메시지는 Merge branch로 시작됩니다.
if: $CUSTOM_VARIABLE !~ /정규식표현/: 사용자 정의 변수 CUSTOM_VARIABLE이 정규식과 일치하지 않는 경우.
if: $CUSTOM_VARIABLE == "value1": 사용자 정의 변수 CUSTOM_VARIABLE이 정확히 value1인 경우 ```

`rules:changes`의 변수

GitLab 13.6에서 도입되었습니다.
GitLab 13.7에서 기능 플래그가 제거되었습니다.

rules:changes 표현식에서 CI/CD 변수를 사용하여 파이프라인에 작업을 추가할 시기를 결정할 수 있습니다:

docker build:
  variables:
    DOCKERFILES_DIR: 'path/to/files'
  script: docker build -t my-image:$CI_COMMIT_REF_SLUG .
  rules:
    - changes:
        - $DOCKERFILES_DIR/*

$ 문자를 변수와 경로 모두에 사용할 수 있습니다. 예를 들어, ‌$DOCKERFILES_DIR 변수가 있으면 해당 값을 사용합니다. 그 변수가 없으면 $는 경로의 일부로 해석됩니다.

다른 작업에서 규칙 재사용

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

다른 작업에서 규칙을 재사용하려면 !reference 태그를 사용하십시오. !reference 규칙을 일반 작업 정의 규칙과 결합할 수 있습니다:

.default_rules:
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"
      when: never
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

job1:
  rules:
    - !reference [.default_rules, rules]
  script:
    - echo "이 작업은 기본 브랜치에 대해 실행되지만 일정에는 실행되지 않습니다."

job2:
  rules:
    - !reference [.default_rules, rules]
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  script:
    - echo "이 작업은 기본 브랜치에 대해 실행되지만 일정에는 실행되지 않습니다."
    - echo "병합 요청에도 실행됩니다."

`only` 및 `except`로 작업 실행 시기 지정

참고: only와 except은 현재 활발하게 개발되고 있지 않습니다. rules는 파이프라인에 작업을 추가하는 용어를 제어하는 데 사용하는 용어입니다.

only와 except를 사용하여 파이프라인에 작업을 추가하는 시기를 제어할 수 있습니다.

only를 사용하여 작업을 실행할 조건을 정의합니다.
except를 사용하여 작업이 실행되지 않을 조건을 정의합니다.

`only:refs` / `except:refs` 예제

only 또는 except를 다음과 함께 사용할 수 있습니다:

특정 키워드. 자세한 목록은 only/except 구문 참조를 참조하세요.
브랜치 이름. 특정 키워드와 정확히 동일한 브랜치 이름을 피하십시오. 예를 들어, tags 키워드(tag 파이프라인)와 정확히 같은 이름의 브랜치를 구성한 작업은 tags라는 이름의 브랜치에서도 실행됩니다.
브랜치 이름의 범위를 지정하는 정규표현식 패턴.

다음의 예에서는 refs를 생략합니다. 왜냐하면 only 또는 except가 refs 없이 사용될 때는 only:refs / except/refs와 같습니다.

예를 들어:

job:
  # 특수 키워드 사용
  only:
    - tags
    - triggers
    - schedules

이 예에서 job은 다음에만 실행됩니다:

상위 저장소에 대해 실행되지만 포크는 실행되지 않도록 작업을 설정하려면:

job:
  only:
    - branches@gitlab-org/gitlab
  except:
    - main@gitlab-org/gitlab
    - /^release/.*$/@gitlab-org/gitlab

이 예제는 main 및 release/로 시작하는 브랜치를 제외하고 gitlab-org/gitlab에서 모든 브랜치에 대해 job을 실행합니다.

`only: variables` / `except: variables` 예제

except:variables를 사용하여 커밋 메시지를 기반으로 작업을 제외할 수 있습니다:

end-to-end:
  script: rake test:end-to-end
  except:
    variables:
      - $CI_COMMIT_MESSAGE =~ /skip-end-to-end-tests/

&& 및 ||와 괄호를 사용하여 더 복잡한 변수 표현식을 작성할 수 있습니다:

job1:
  script:
    - echo 이 규칙은 괄호를 사용합니다.
  only:
    variables:
      - ($CI_COMMIT_BRANCH == "main" || $CI_COMMIT_BRANCH == "develop") && $MY_VARIABLE

only:variables에 여러 항목이 지정된 경우 적어도 하나가 true로 평가될 때 작업을 실행합니다. 여러 조건을 동시에 충족해야 하는 경우 단일 항목에 &&를 사용할 수 있습니다.

`only:changes` / `except:changes` 예제

.md 확장자를 가진 파일이 루트 디렉토리에 있는 경우 변경이 감지된다면 작업을 건너뛸 수 있습니다.

build:
  script: npm run build
  except:
    changes:
      - "*.md"

여러 파일을 변경했지만 하나의 파일만 .md로 끝나는 경우에도 build 작업은 여전히 건너뜁니다. 이 작업은 어떠한 파일에 대해서도 실행되지 않습니다.

changes를 사용하는 일부 구성에서는 작업이 예상치 못하게 실행될 수 있습니다.

병합 요청 파이프라인에서 `only:changes` 사용

병합 요청 파이프라인에서는 병합 요청에서 수정된 파일을 기반으로 작업을 정의할 수 있습니다.

only: [merge_requests] 키워드를 only와 함께 사용하여 GitLab이 소스 브랜치의 올바른 기본 SHA를 찾을 수 있도록 할 수 있습니다. 파일 차이는 추가로 커밋된 파일에서 올바르게 계산되며, 병합 요청의 모든 변경 사항이 파이프라인에서 올바르게 테스트됩니다.

예를 들어:

docker build service one:
  script: docker build -t my-service-one-image:$CI_COMMIT_REF_SLUG .
  only:
    refs:
      - merge_requests
    changes:
      - Dockerfile
      - service-one/**/*

이 시나리오에서, 병합 요청이 service-one 디렉터리나 Dockerfile에서 파일을 변경한다면, GitLab은 docker build service one 작업을 생성합니다.

예를 들어:

docker build service one:
  script: docker build -t my-service-one-image:$CI_COMMIT_REF_SLUG .
  only:
    changes:
      - Dockerfile
      - service-one/**/*

이 예에서는 service-one/**/* 파일에 변경이 있기 때문에 파이프라인이 실패할 수 있습니다.

service-one/**/*에 변경 사항이 없는 후속 커밋은 성공할 수 있습니다. 하지만 Dockerfile에 대한 변경으로 실패한 경우에 작업은 Dockerfile에 대한 변경만 테스트합니다.

GitLab은 최근에 통과한 파이프라인을 확인합니다. 병합 요청이 병합 가능한지 여부는, 이전 파이프라인에서 수정되지 않은 변경으로 인해 이전 파이프라인이 실패했다는 것은 중요하지 않습니다.

이 구성을 사용할 때는, 최근 파이프라인이 이전 파이프라인의 실패를 올바르게 수정하는지 확인하세요.

`only` 또는 `except`로 여러 키워드 조합하기

only 또는 except와 여러 키워드를 함께 사용하는 경우, 키워드는 단일 연결 표현식으로 평가됩니다. 즉,

only는 모든 키가 하나 이상 일치하는 조건을 갖는 경우 작업을 포함합니다.
except는 어떤 키가 하나 이상 일치하는 조건을 갖는 경우 작업을 제외합니다.

only에서 개별 키워드는 논리적으로 AND로 연결됩니다. 작업이 파이프라인에 추가되려면 다음이 참이어야 합니다:

(나열된 refs 중 하나가 참) AND (나열된 변수 중 하나가 참) AND (나열된 변경 사항 중 하나가 참) AND (선택한 Kubernetes 상태가 일치)

다음 예에서 test 작업은 다음의 모든 조건이 참일 때에만 생성됩니다:

파이프라인이 예약됨 또는 main에서 실행됩니다.
variables 키워드가 일치합니다.
프로젝트에서 kubernetes 서비스가 활성화되어 있습니다.

test:
  script: npm run test
  only:
    refs:
      - main
      - schedules
    variables:
      - $CI_COMMIT_MESSAGE =~ /run-end-to-end-tests/
    kubernetes: active

except에서는 개별 키워드가 논리적으로 OR로 연결됩니다. 다음이 참이면 작업은 추가되지 않습니다:

나열된 refs 중 하나가 참이거나
나열된 변수 중 하나가 참이거나
나열된 변경 사항 중 하나가 참이거나
선택한 Kubernetes 상태가 일치합니다

다음 예에서 test 작업은 다음 중 어떤 것이라도 참인 경우 작업이 추가되지 않습니다:

파이프라인이 main 브랜치에서 실행됩니다.
루트 디렉토리의 README.md 파일에 변경 사항이 있습니다.

test:
  script: npm run test
  except:
    refs:
      - main
    changes:
      - "README.md"

수동으로 실행해야 하는 작업 만들기

작업이 사용자가 시작할 때까지 실행되지 않도록 요구할 수 있습니다. 이를 수동 작업이라고 합니다. 예를 들어 프로덕션 환경으로 배포하는 경우에 수동 작업을 사용하고자 할 수 있습니다.

작업을 수동으로 지정하려면 .gitlab-ci.yml 파일의 작업에 when: manual을 추가하세요.

기본적으로 수동 작업은 파이프라인이 시작될 때 건너뛰어진 것으로 표시됩니다.

보호된 브랜치를 사용하여 권한이 없는 사용자에 의해 수동 배포가 방지될 수 있습니다.

수동 작업 유형

수동 작업은 선택적 또는 차단될 수 있습니다.

선택적 수동 작업의 경우:

allow_failure이 true이며, 이것은when: manual 및 rules이 없는 작업에 대한 기본 설정이거나 외부의rules에서 정의된when: manual이 있습니다.
상태는 전체 파이프라인 상태에 기여하지 않습니다. 모든 수동 작업이 실패해도 파이프라인이 성공할 수 있습니다.

차단된 수동 작업의 경우:

allow_failure이 false이며, 이것은rules 내에서 정의된when: manual을 가진 작업에 대한 기본 설정입니다.
파이프라인은 작업이 정의된 단계에서 중지됩니다. 파이프라인을 계속 실행하려면 수동 작업을 실행하세요.
활성화된 Pipelines must succeed가 있는 프로젝트의 병합 요청은 차단된 파이프라인으로 병합될 수 없습니다.
파이프라인은 blocked 상태를 표시합니다.

strategy: depend로 트리거된 파이프라인에서 수동 작업을 사용할 때 수동 작업 유형은 파이프라인이 실행되는 동안 트리거 작업의 상태에 영향을 미칠 수 있습니다.

수동 작업 실행

수동 작업을 실행하려면 할당된 브랜치에 병합할 수 있는 권한이 있어야 합니다:

파이프라인, 작업, 환경, 또는 배포 보기로 이동합니다
수동 작업 옆에서 Play ()를 선택합니다.

또한 수동 작업 실행 시 사용자 정의 CI/CD 변수 추가하기가 가능합니다.

수동 작업 보호

세부 정보: Tier: Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

보호된 환경을 사용하여 수동 작업을 실행할 권한이있는 사용자 목록을 정의할 수 있습니다. 보호된 환경과 관련된 사용자들만 수동 작업을 트리거할 수 있도록 권한을 부여할 수 있으며 이로써: - 특정 환경으로 배포할 수 있는 사용자를 더 정확하게 제한할 수 있습니다. - 승인된 사용자가 승인할 때까지 파이프라인을 차단할 수 있습니다.

수동 작업을 보호하려면:

작업에 environment를 추가합니다. 예를 들어:

deploy_prod:
  stage: deploy
  script:
    - echo "Production 서버에 배포"
  environment:
    name: production
    url: https://example.com
  when: manual
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

보호된 환경 설정에서 환경(production 예시)을 선택하고 권한이 있는 사용자, 역할 또는 그룹을 허용된 배포 목록에 추가합니다. 이 목록에 있는 사용자와 GitLab 관리자는 항상 보호된 환경을 사용할 수 있습니다.

차단된 수동 작업과 함께 보호된 환경을 사용하여 나중에 승인할 수 있는 사용자 목록을 설정할 수 있습니다. 보호된 수동 작업에 allow_failure: false를 추가하고, 허가된 사용자에 의해 수동으로 작업이 트리거된 후에 파이프라인의 다음 단계만 실행됩니다.

지연 후 작업 실행

GitLab 11.4에 도입됨.

when: delayed를 사용하여 대기 기간 후에 스크립트를 실행하거나 작업이 즉시 pending 상태가 되는 것을 피하고 싶은 경우 사용합니다.

start_in 키워드로 기간을 설정할 수 있습니다. start_in의 값은 초 단위의 경과 시간이며, 단위가 제공되지 않으면 최소값은 1초이고 최대값은 1주일입니다. 유효한 값의 예시는 다음과 같습니다:

'5' (단위가 없는 값은 따옴표로 둘러싸여야 함)
5 seconds
30 minutes
1 day
1 week

지연된 작업이 포함된 단계는 지연된 작업이 완료될 때까지 파이프라인이 진행되지 않습니다. 이 키워드를 사용하여 다른 단계 간의 지연을 삽입할 수 있습니다.

지연된 작업의 타이머는 이전 단계가 완료된 후 즉시 시작됩니다. 다른 종류의 작업과 마찬가지로, 지연된 작업의 타이머는 이전 단계가 통과되지 않으면 시작하지 않습니다.

다음 예시는 이전 단계 완료 후 30분 후에 실행되는 timed rollout 10%라는 작업을 생성합니다:

timed rollout 10%:
  stage: deploy
  script: echo '10% 배포중...'
  when: delayed
  start_in: 30 minutes
  environment: production

지연된 작업의 활성 타이머를 중지하려면 Unschedule ()을 선택합니다. 이 작업은 더 이상 자동으로 예약되지 않습니다. 그러나 수동으로 실행할 수 있습니다.

지연된 작업을 수동으로 시작하려면 Unschedule ()을 선택하여 지연 타이머를 중지한 후 Play ()를 선택합니다. 곧바로 GitLab Runner가 작업을 시작합니다.

대규모 작업 병렬화

대규모 작업을 여러 개의 작은 작업으로 나누어 병렬로 실행하려면 .gitlab-ci.yml 파일에서 parallel 키워드를 사용합니다.

다양한 언어 및 테스트 스위트에는 병렬 처리를 활성화하는 여러 가지 방법이 있습니다. 예를 들어, 세마포어 테스트 부스터 및 RSpec을 사용하여 루비 테스트를 병렬로 실행할 수 있습니다:

# Gemfile
source 'https://rubygems.org'

gem 'rspec'
gem 'semaphore_test_boosters'

test:
  parallel: 3
  script:
    - bundle
    - bundle exec rspec_booster --job $CI_NODE_INDEX/$CI_NODE_TOTAL

그런 다음 새로운 파이프라인 빌드의 작업 탭으로 이동하여 RSpec 작업이 세 개의 별도 작업으로 분할되는 것을 볼 수 있습니다.

경고: 테스트 부스터가 저자에게 사용 통계를 보냅니다.

일차원 행렬의 병렬 작업 실행

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

일차원 행렬의 병렬 작업을 생성할 수 있습니다:

deploystacks:
  stage: deploy
  script:
    - bin/deploy
  parallel:
    matrix:
      - PROVIDER: [aws, ovh, gcp, vultr]
  environment: production/$PROVIDER

또한 다차원 행렬을 생성할 수도 있습니다.

병렬 트리거 작업의 행렬 실행

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

단일 파이프라인에서 트리거 작업을 병렬로 여러 번 실행할 수 있지만, 작업의 각 인스턴스마다 다른 변수 값을 사용할 수 있습니다.

deploystacks:
  stage: deploy
  trigger:
    include: path/to/child-pipeline.yml
  parallel:
    matrix:
      - PROVIDER: aws
        STACK: [monitoring, app1]
      - PROVIDER: ovh
        STACK: [monitoring, backup]
      - PROVIDER: [gcp, vultr]
        STACK: [data]

이 예제는 PROVIDER와 STACK에 대해 서로 다른 값으로 6개의 병렬 deploystacks 트리거 작업을 생성하며, 이러한 변수를 사용하여 6개의 다른 하위 파이프라인을 만듭니다.

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

병렬 행렬 작업마다 다른 러너 태그 선택

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

병렬: 행렬에서 정의된 변수를 동적 러너 선택을 위한 [tags`](../yaml/index.md#tags) 키워드와 함께 사용할 수 있습니다:

deploystacks:
  stage: deploy
  parallel:
    matrix:
      - PROVIDER: aws
        STACK: [monitoring, app1]
      - PROVIDER: gcp
        STACK: [data]
  tags:
    - ${PROVIDER}-${STACK}
  environment: $PROVIDER/$STACK

`parallel:matrix` 작업에서 아티팩트 가져오기

parallel:matrix로 생성된 작업에서 아티팩트를 가져올 수 있으며, 이때 dependencies 키워드를 사용합니다. dependencies에는 다음과 같은 형식의 문자열로 작업 이름을 사용합니다:

<job_name> [<matrix argument 1>, <matrix argument 2>, ... <matrix argument N>]

예를 들어, RUBY_VERSION이 2.7이고 PROVIDER가 aws인 작업으로부터 아티팩트를 가져오려면:

ruby:
  image: ruby:${RUBY_VERSION}
  parallel:
    matrix:
      - RUBY_VERSION: ["2.5", "2.6", "2.7", "3.0", "3.1"]
        PROVIDER: [aws, gcp]
  script: bundle install

deploy:
  image: ruby:2.7
  stage: deploy
  dependencies:
    - "ruby: [2.7, aws]"
  script: echo hello
  environment: production

dependencies 항목 주위에 따옰표가 필요합니다.

여러 병렬화된 작업을 needs로 지정하기

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

여러 병렬화된 작업에서 needs:parallel:matrix로 정의된 변수를 사용할 수 있습니다.

예를 들어:

linux:build:
  stage: build
  script: echo "Linux 빌드 중..."
  parallel:
    matrix:
      - PROVIDER: aws
        STACK:
          - monitoring
          - app1
          - app2

mac:build:
  stage: build
  script: echo "mac 빌드 중..."
  parallel:
    matrix:
      - PROVIDER: [gcp, vultr]
        STACK: [data, processing]

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

mac:rspec:
  stage: test
  needs:
    - job: mac:build
      parallel:
        matrix:
          - PROVIDER: [gcp, vultr]
            STACK: [data]
  script: echo "Mac에서 rspec 실행 중..."

production:
  stage: deploy
  script: echo "배포 중..."
  environment: production

이 예제에서는 여러 작업이 생성됩니다. 각 병렬 작업은 PROVIDER 및 STACK에 대해 서로 다른 값을 가집니다.

3개의 병렬 linux:build 작업:
- linux:build: [aws, monitoring]
- linux:build: [aws, app1]
- linux:build: [aws, app2]
4개의 병렬 mac:build 작업:
- mac:build: [gcp, data]
- mac:build: [gcp, processing]
- mac:build: [vultr, data]
- mac:build: [vultr, processing]
linux:rspec 작업
production 작업

작업에는 세 가지 실행 경로가 있습니다:

Linux 경로: linux:rspec 작업은 linux:build: [aws, app1] 작업이 완료되는 즉시 실행되며, mac:build의 완료를 기다리지 않습니다.
macOS 경로: mac:rspec 작업은 mac:build: [gcp, data] 및 mac:build: [vultr, data] 작업이 완료되는 즉시 실행되며, linux:build의 완료를 기다리지 않습니다.
모든 이전 작업이 완료되는 즉시 production 작업이 실행됩니다.

미리 정의된 CI/CD 변수를 사용하여 특정 파이프라인 유형에서 작업 실행

다음과 같이 미리 정의된 CI/CD 변수를 사용하여 다음과 같은 파이프라인 유형에서 작업을 실행할 수 있습니다.

다음 표는 사용할 수 있는 몇 가지 변수와 변수가 제어할 수 있는 파이프라인 유형을 나열합니다:

브랜치 파이프라인: 브랜치에 대한 Git push 이벤트의 실행으로 새로운 커밋 또는 태그와 같은 것들
태그 파이프라인: 새로운 Git 태그가 브랜치로 푸시될 때만 실행
병합 요청 파이프라인: 병합 요청에 대한 변경 사항의 실행으로 새로운 커밋 또는 병합 요청의 파이프라인 탭에서 파이프라인 실행 버튼을 선택하는 것과 같은 것들
예약된 파이프라인

변수	브랜치	태그	병합 요청	예약된
`CI_COMMIT_BRANCH`	Yes			Yes
`CI_COMMIT_TAG`		Yes		Yes, 예약된 파이프라인이 태그에서 실행되도록 구성된 경우에만 실행됨
`CI_PIPELINE_SOURCE = push`	Yes	Yes
`CI_PIPELINE_SOURCE = schedule`				Yes
`CI_PIPELINE_SOURCE = merge_request_event`			Yes
`CI_MERGE_REQUEST_IID`			Yes

예를 들어, 병합 요청 파이프라인 및 예약된 파이프라인에서만 실행되도록 작업을 구성하려면 다음과 같이 할 수 있습니다:

job1:
  script:
    - echo
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_PIPELINE_SOURCE == "schedule"
    - if: $CI_PIPELINE_SOURCE == "push"
      when: never

정규 표현식

@ 기호는 참조 리포지토리 경로의 시작을 나타냅니다. 정규 표현식에서 @ 문자를 포함하는 참조 이름을 일치시키려면 16진수 문자 코드 일치 \x40를 사용해야 합니다.

태그 또는 브랜치 이름만 정규 표현식으로 일치시킬 수 있습니다. 지정된 경우 리포지토리 경로는 항상 글자 그대로 일치됩니다.

태그 또는 브랜치 이름을 일치시키려면 패턴의 전체 참조 이름 부분은 반드시 /로 둘러싸인 정규 표현식이어야 합니다. 예를 들어, issue-/.*/를 사용하여 issue-로 시작하는 모든 태그 이름 또는 브랜치 이름을 일치시킬 수 없지만, /issue-.*/를 사용할 수 있습니다.

대소문자를 구분하는 일치 기본적으로 대소문자를 구분합니다. 패턴을 대소문자 구분 없이 만들려면 /pattern/i와 같이 i 플래그 수정자를 사용하십시오:

job:
  # 정규 표현식 사용
  only:
    - /^issue-.*$/i
  # 특수 키워드 사용
  except:
    - branches

^와 $ 앵커를 사용하여 정규 표현식이 태그 이름이나 브랜치 이름의 부분 문자열만 일치시키는 것을 피하십시오. 예를 들어, /^issue-.*$/은 /^issue-/과 동일하지만, 단순히 /issue/는 severe-issues라는 브랜치도 일치시킵니다.

`only` / `except` 정규 표현식 구문

GitLab 11.9.4에서 GitLab은 only 및 except 키워드에서 사용된 정규 표현식을 RE2로 내부적으로 전환하기 시작했습니다.

RE2는 계산 복잡성으로 인해 사용 가능한 기능 집합을 제한하였으며, 부정적인 룩어헤드와 같은 일부 기능이 사용할 수 없었습니다. Ruby Regexp에서 제공하는 기능 중 일부만 지원됩니다.

GitLab 11.9.7부터 GitLab 14.9까지, GitLab은 안전하지 않은 정규 표현식 구문을 사용할 수 있도록하는 기능 플래그를 제공했습니다. 우리는 이제 완전히 RE2로 마이그레이션하였으며, 해당 기능 플래그는 더 이상 사용할 수 없습니다.

CI/CD 변수 표현식

GitLab 10.7에서 only 및 except CI 키워드를 위해 도입되었습니다.
GitLab 12.3에서 rules 키워드와 함께 확장되었습니다.

GitLab에 변경 사항이 푸시된 후에 파이프라인에서 생성되는 작업을 제어하기 위해 변수 표현식을 사용할 수 있습니다. 변수 표현식은 다음과 함께 사용할 수 있습니다:

예를 들어, rules:if를 사용하는 경우:

job1:
  variables:
    VAR1: "variable1"
  script:
    - echo "변수 비교를 테스트합니다."
  rules:
    - if: $VAR1 == "variable1"

변수를 문자열과 비교

변수와 문자열을 비교하려면 동등 연산자 == 및 !=를 사용할 수 있습니다. 작은 따옴표와 큰 따옴표 모두 유효합니다. 순서는 중요하지 않으며, 변수가 먼저 와도 되고 문자열이 먼저와도 됩니다. 예를 들면:

if: $VARIABLE == "some value"
if: $VARIABLE != "some value"
if: "some value" == $VARIABLE

두 변수를 비교

두 변수의 값을 비교할 수 있습니다. 예를 들면:

if: $VARIABLE_1 == $VARIABLE_2
if: $VARIABLE_1 != $VARIABLE_2

변수가 정의되지 않았는지 확인

변수를 null 키워드와 비교하여 정의되었는지 확인할 수 있습니다. 예를 들면:

if: $VARIABLE == null
if: $VARIABLE != null

변수가 비어 있는지 확인

변수가 정의되었지만 비어 있는지 확인할 수 있습니다. 예를 들면:

if: $VARIABLE == ""
if: $VARIABLE != ""

변수의 존재 여부 확인

식에서 변수 이름만 사용하여 변수의 존재 여부를 확인할 수 있습니다. 변수는 비어 있으면 안 됩니다. 예를 들면:

if: $VARIABLE

변수를 정규 표현식 패턴과 비교

변수 값에 대해 정규 표현식 패턴 매칭을 사용하여 =~ 및 !~ 연산자로 수행할 수 있습니다. 정규 표현식을 사용한 변수 패턴 매칭은 RE2 regular expression syntax를 사용합니다.

식은 다음과 같이 true로 평가됩니다:

=~ 사용 시 일치 항목을 찾은 경우
!~ 사용 시 일치 항목을 찾지 않은 경우

예를 들면:

if: $VARIABLE =~ /^content.*/
if: $VARIABLE !~ /^content.*/

단일 문자 정규 표현식(/./)은 지원되지 않으며 유효하지 않은 표현 구문 오류가 발생합니다.

기본적으로 패턴 매칭은 대소문자를 구분합니다. 패턴을 대소문자 구분 없이 만들려면 i 플래그 수정자를 사용하십시오. 예를 들면: /pattern/i.

참고: =~ 문자를 사용할 때 비교의 오른쪽에 항상 유효한 정규 표현식이 포함되어 있는지 확인하십시오. 비교의 오른쪽이 / 문자로 둘러싸인 유효한 정규 표현식이 아닌 경우 식이 예상과 다르게 평가됩니다. 이 경우 비교는 왼쪽 항목이 오른쪽 항목의 부분 문자열인지 확인합니다. 예를 들면, "23" =~ "1234" 은 true로 평가되며, "23" =~ /1234/의 경우에는 false로 평가됩니다. 이러한 동작에 의존하여 파이프라인을 구성해서는 안 됩니다.

정규 표현식 패턴을 변수에 저장

GitLab 15.0에서 도입됨. 기본적으로 비활성화된 ci_fix_rules_if_comparison_with_regexp_variable 플래그 사용.
GitLab 15.1에서 기능 사용 가능, ci_fix_rules_if_comparison_with_regexp_variable 플래그 제거.

=~ 및 !~ 표현식의 오른쪽에 변수를 사용하여 변수를 정규 표현식으로 평가합니다. 정규 표현식은 반드시 슬래시 (/)로 둘러싸여 있어야 합니다. 예를 들면:

variables:
  pattern: '/^ab.*/'

regex-job1:
  variables:
    teststring: 'abcde'
  script: echo "'abcde'가 /^ab.*/ 패턴과 일치하므로 이 작업이 실행됩니다."
  rules:
    - if: '$teststring =~ $pattern'

regex-job2:
  variables:
    teststring: 'fghij'
  script: echo "'fghi'가 /^ab.*/ 패턴과 일치하지 않으므로 이 작업이 실행되지 않습니다."
  rules:
    - if: '$teststring =~ $pattern'

`&&` 또는 `||`로 변수 표현식 결합

GitLab 12.0에서 도입됨.

여러 표현식을 && (그리고) 또는 || (또는)으로 결합할 수 있습니다. 예를 들면:

$VARIABLE1 =~ /^content.*/ && $VARIABLE2 == "something"
$VARIABLE1 =~ /^content.*/ && $VARIABLE2 =~ /thing$/ && $VARIABLE3
$VARIABLE1 =~ /^content.*/ || $VARIABLE2 =~ /thing$/ && $VARIABLE3

연산자의 우선 순위는 루비 2.5 표준을 따르므로 &&가 ||보다 먼저 계산됩니다.

괄호로 그룹 변수 표현식 묶기

GitLab 13.3에서 도입되었습니다.
GitLab 13.5에서 기능 플래그가 제거되었습니다.

여러 표현식을 그룹화하기 위해 괄호를 사용할 수 있습니다. 괄호는 &&와 ||보다 우선순위가 높기 때문에 괄호로 둘러싼 표현식이 먼저 계산되고 결과가 나머지 표현식에 사용됩니다.

복잡한 조건을 만들기 위해 괄호를 중첩시킬 수 있으며, 괄호로 둘러싸인 가장 안쪽 표현식이 먼저 계산됩니다.

예를 들어:

($VARIABLE1 =~ /^content.*/ || $VARIABLE2) && ($VARIABLE3 =~ /thing$/ || $VARIABLE4)
($VARIABLE1 =~ /^content.*/ || $VARIABLE2 =~ /thing$/) && $VARIABLE3
$CI_COMMIT_BRANCH == "my-branch" || (($VARIABLE1 == "thing" || $VARIABLE2 == "thing") && $VARIABLE3)

작업 실행 시기 선택

rules로 작업 실행 시기 지정

rules 예

예약된 파이프라인을 위해 작업 실행

브랜치가 비어 있는 경우 작업 건너뛰기

중복 파이프라인 피하기

rules를 위한 공통 if 절

rules:changes의 변수

다른 작업에서 규칙 재사용

only 및 except로 작업 실행 시기 지정

only:refs / except:refs 예제

only: variables / except: variables 예제

only:changes / except:changes 예제

병합 요청 파이프라인에서 only:changes 사용

only 또는 except로 여러 키워드 조합하기

수동으로 실행해야 하는 작업 만들기

수동 작업 유형

수동 작업 실행

수동 작업 보호

지연 후 작업 실행

대규모 작업 병렬화

일차원 행렬의 병렬 작업 실행

병렬 트리거 작업의 행렬 실행

병렬 행렬 작업마다 다른 러너 태그 선택

parallel:matrix 작업에서 아티팩트 가져오기

여러 병렬화된 작업을 needs로 지정하기

미리 정의된 CI/CD 변수를 사용하여 특정 파이프라인 유형에서 작업 실행

정규 표현식

only / except 정규 표현식 구문

CI/CD 변수 표현식

변수를 문자열과 비교

두 변수를 비교

변수가 정의되지 않았는지 확인

변수가 비어 있는지 확인

변수의 존재 여부 확인

변수를 정규 표현식 패턴과 비교

정규 표현식 패턴을 변수에 저장

&& 또는 ||로 변수 표현식 결합

괄호로 그룹 변수 표현식 묶기

도움말

기능 사용 가능성과 제품 평가판

도움받기

`rules`로 작업 실행 시기 지정

`rules` 예

`rules`를 위한 공통 `if` 절

`rules:changes`의 변수

`only` 및 `except`로 작업 실행 시기 지정

`only:refs` / `except:refs` 예제

`only: variables` / `except: variables` 예제

`only:changes` / `except:changes` 예제

병합 요청 파이프라인에서 `only:changes` 사용

`only` 또는 `except`로 여러 키워드 조합하기

`parallel:matrix` 작업에서 아티팩트 가져오기

`only` / `except` 정규 표현식 구문

`&&` 또는 `||`로 변수 표현식 결합