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

workflow 키워드는 job 전에 평가됩니다. 예를 들어, job이 태그에 대해 실행되도록 구성되어 있지만 workflow가 태그 파이프라인을 차단하면, job은 실행되지 않습니다.

workflow:rules에 대한 일반적인 if 절#

workflow: rules에 대한 일부 예시 if 절:

더 많은 예시는 rules에 대한 일반적인 if 절을 참조하세요.

workflow: rules 예시#

다음 예시에서:

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

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
    - # 이전에 정의된 workflow 규칙

트리거된 파이프라인이 브랜치에서 실행되면 $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로 인한 것일 수 있습니다. 이 문제는 프로젝트에서 파이프라인이 성공해야 함이 활성화되어 있지만, workflow:rules가 머지 리퀘스트에 대한 파이프라인 실행을 차단하는 경우 발생할 수 있습니다.

예를 들어, 다음 workflow에서는 파이프라인이 실행될 수 없으므로 머지 리퀘스트를 머지할 수 없습니다:

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