.gitlab-ci.yml 파일에서 workflow 키워드를 사용하여 파이프라인이 언제 생성되는지 제어합니다.

workflow 키워드는 job보다 먼저 평가됩니다. 예를 들어 어떤 job이 태그에 대해 실행되도록 구성되어 있더라도, workflow가 태그 파이프라인을 막으면 해당 job은 절대 실행되지 않습니다.

workflow:rules에서 자주 사용하는 if 절#

workflow: rules에 사용할 수 있는 if 절의 예시입니다:

더 많은 예시는 rules에 자주 사용하는 if 절을 참고합니다.

workflow: rules 예시#

다음 예시에서는 다음과 같이 동작합니다:

• 모든 push 이벤트(브랜치에 대한 변경 및 새 태그)에 대해 파이프라인이 실행됩니다.
• 커밋 메시지가 -draft로 끝나는 push 이벤트에 대한 파이프라인은 when: never로 설정되어 있으므로 실행되지 않습니다.
• 스케줄이나 머지 리퀘스트에 대한 파이프라인도 실행되지 않는데, 이는 해당 파이프라인에 대해 참으로 평가되는 규칙이 없기 때문입니다.

workflow:
  rules:
    - if: $CI_COMMIT_MESSAGE =~ /-draft$/
      when: never
    - if: $CI_PIPELINE_SOURCE == "push"

이 예시는 엄격한 규칙을 사용하므로, 그 외의 경우에는 파이프라인이 실행되지 않습니다.

다른 방법으로는, 모든 규칙을 when: never로 설정하고 마지막에 when: always 규칙을 두는 방법도 있습니다. when: never 규칙과 일치하는 파이프라인은 실행되지 않으며, 그 외의 모든 파이프라인 유형은 실행됩니다. 예를 들면 다음과 같습니다:

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "schedule"
      when: never
    - if: $CI_PIPELINE_SOURCE == "push"
      when: never
    - when: always

이 예시는 스케줄 파이프라인 또는 push(브랜치 및 태그) 파이프라인의 실행을 막습니다. 마지막 when: always 규칙은 머지 리퀘스트 파이프라인을 포함한 그 외의 모든 파이프라인 유형을 실행합니다.

브랜치 파이프라인과 머지 리퀘스트 파이프라인 간 전환#

머지 리퀘스트가 생성된 후 파이프라인이 브랜치 파이프라인에서 머지 리퀘스트 파이프라인으로 전환되도록 하려면, .gitlab-ci.yml 파일에 workflow: rules 섹션을 추가합니다.

두 파이프라인 유형을 동시에 사용하면 중복 파이프라인이 동시에 실행될 수 있습니다. 중복 파이프라인을 방지하려면 CI_OPEN_MERGE_REQUESTS 변수를 사용합니다.

다음 예시는 브랜치 파이프라인과 머지 리퀘스트 파이프라인만 실행하고, 그 외의 경우에는 파이프라인을 실행하지 않는 프로젝트를 위한 것입니다. 다음을 실행합니다:

• 해당 브랜치에 열려 있는 머지 리퀘스트가 없을 때의 브랜치 파이프라인.
• 해당 브랜치에 머지 리퀘스트가 열려 있을 때의 머지 리퀘스트 파이프라인.

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS
      when: never
    - if: $CI_COMMIT_BRANCH

GitLab이 다음을 트리거하려고 시도하는 경우:

• 머지 리퀘스트 파이프라인인 경우, 파이프라인을 시작합니다. 예를 들어 머지 리퀘스트 파이프라인은 열려 있는 머지 리퀘스트와 연결된 브랜치에 대한 push로 트리거될 수 있습니다.
• 브랜치 파이프라인이지만 해당 브랜치에 머지 리퀘스트가 열려 있는 경우, 브랜치 파이프라인을 실행하지 않습니다. 예를 들어 브랜치 파이프라인은 브랜치 변경, API 호출, 또는 예약된 파이프라인으로 트리거될 수 있습니다.
• 브랜치 파이프라인이며 해당 브랜치에 열려 있는 머지 리퀘스트가 없는 경우, 브랜치 파이프라인을 실행합니다.

머지 리퀘스트가 생성될 때 브랜치 파이프라인에서 머지 리퀘스트 파이프라인으로 전환하도록, 기존 workflow 섹션에 규칙을 추가할 수도 있습니다.

이 규칙을 workflow 섹션의 맨 위에 추가하고, 그 뒤에 기존에 있던 다른 규칙을 배치합니다:

workflow:
  rules:
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS && $CI_PIPELINE_SOURCE == "push"
      when: never
    - # Previously defined workflow rules here

브랜치에서 실행되는 트리거된 파이프라인은 $CI_COMMIT_BRANCH가 설정되어 있어 유사한 규칙에 의해 차단될 수 있습니다. 트리거된 파이프라인의 파이프라인 소스는 trigger 또는 pipeline이므로, && $CI_PIPELINE_SOURCE == "push"를 추가하면 해당 규칙이 트리거된 파이프라인을 차단하지 않도록 보장할 수 있습니다.

머지 리퀘스트 파이프라인을 사용하는 Git Flow#

머지 리퀘스트 파이프라인과 함께 workflow: rules를 사용할 수 있습니다. 이러한 규칙을 사용하면 소프트웨어의 여러 버전을 지원하는 장기 브랜치를 유지하면서, 피처 브랜치에서 머지 리퀘스트 파이프라인 기능을 사용할 수 있습니다.

예를 들어 머지 리퀘스트, 태그, 보호된 브랜치에 대해서만 파이프라인을 실행하려면 다음과 같이 작성합니다:

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_TAG
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    - if: $CI_COMMIT_REF_PROTECTED == "true"

이 예시는 기본 브랜치 또는 다른 장기 브랜치가 보호되어 있다고 가정합니다.

드래프트 머지 리퀘스트의 파이프라인 건너뛰기#

workflow: rules를 사용하여 드래프트 머지 리퀘스트의 파이프라인을 건너뛸 수 있습니다. 이 방법은 개발이 완료될 때까지 컴퓨팅 리소스를 절약합니다.

머지 리퀘스트가 드래프트 상태인지 확인하려면 CI_MERGE_REQUEST_DRAFT 변수를 사용합니다. 이 변수는 GitLab이 지원하는 모든 드래프트 형식을 자동으로 감지합니다.

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event" && $CI_MERGE_REQUEST_DRAFT == "true"
      when: never
    - when: always

stages:
  - build

build-job:
  stage: build
  script:
    - echo "Testing"

문제 해결#

머지 리퀘스트가 Checking pipeline status. 메시지에서 멈추는 경우#

머지 리퀘스트에 Checking pipeline status. 메시지가 표시된 채로 사라지지 않는 경우 ("스피너"가 계속 회전하는 경우), 이는 workflow:rules 때문일 수 있습니다. 이 문제는 프로젝트에서 Pipelines must succeed가 활성화되어 있지만 workflow:rules가 해당 머지 리퀘스트에 대한 파이프라인 실행을 막고 있을 때 발생할 수 있습니다.

예를 들어 다음과 같은 workflow에서는, 실행 가능한 파이프라인이 없기 때문에 머지 리퀘스트를 머지할 수 없습니다:

workflow:
  rules:
    - changes:
        - .gitlab/**/**.md
      when: never