하류 파이프라인

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

하류 파이프라인은 다른 파이프라인에 의해 트리거되는 모든 GitLab CI/CD 파이프라인입니다. 하류 파이프라인은 트리거한 상류 파이프라인과 독립적으로 동시에 실행됩니다.

부모-자식 파이프라인과 다중 프로젝트 파이프라인은 때로는 비슷한 목적으로 사용할 수 있지만, 주요 차이점이 있습니다.

부모-자식 파이프라인

부모 파이프라인은 동일한 프로젝트에서 하류 파이프라인을 트리거하는 파이프라인입니다. 하류 파이프라인은 자식 파이프라인이라고 합니다.

자식 파이프라인:

  • 부모 파이프라인과 동일한 프로젝트, 참조, 및 커밋 SHA에서 실행됩니다.
  • 파이프라인의 ref의 전체 상태에 직간접적인 영향을 미치지 않습니다. 예를 들어, 메인 브랜치의 파이프라인이 실패하면 “메인이 망가졌다”고 말하는 것이 보통입니다. 자식 파이프라인의 상태는 자식 파이프라인이 strategy:depend로 트리거된 경우에만 ref의 상태에 영향을 줍니다.
  • 새로운 파이프라인이 동일한 ref에 대해 생성되었을 때, 파이프라인이 interruptible 로 구성된 경우 자동으로 취소됩니다.
  • 프로젝트의 파이프라인 디렉터리에 표시되지 않습니다. 자식 파이프라인은 부모 파이프라인의 세부 정보 페이지에서만 볼 수 있습니다.

중첩된 자식 파이프라인

부모와 자식 파이프라인은 최대 두 수준의 자식 파이프라인을 가질 수 있습니다.

부모 파이프라인은 많은 자식 파이프라인을 트리거할 수 있으며, 이러한 자식 파이프라인은 자체의 자식 파이프라인을 트리거할 수 있습니다. 다른 수준의 자식 파이프라인을 트리거할 수는 없습니다.

개요는 중첩 동적 파이프라인을 참조하세요.

다중 프로젝트 파이프라인

한 프로젝트의 파이프라인은 다른 프로젝트에서 하류 파이프라인을 트리거할 수 있습니다. 이를 다중 프로젝트 파이프라인이라고 합니다. 상류(트리거) 파이프라인을 시작하는 사용자는 다운스트림 프로젝트에서 파이프라인을 시작할 수 있어야 하며, 그렇지 않으면 다운스트림 파이프라인이 시작하지 못합니다.

다중 프로젝트 파이프라인:

  • 다른 프로젝트의 파이프라인에서 트리거됩니다. 그러나 상류(트리거) 파이프라인은 다운스트림(트리거된) 파이프라인에 대해 크게 제어할 수 없습니다. 그러나 다운스트림 파이프라인의 ref를 선택하고 CI/CD 변수를 전달할 수는 있습니다.
  • 프로젝트의 ref의 전체 상태에 영향을 미칩니다. 그러나 상류(트리거) 파이프라인의 ref의 상태에 영향을 미치지 않으며, strategy:depend로 트리거된 경우에만 영향을 줍니다.
  • 상류(트리거) 파이프라인의 ref에 대해 같은 ref에 대한 새 파이프라인이 실행되면 다운스트림 프로젝트에서 자동으로 취소되지 않습니다. 다운스트림 프로젝트에서 동일한 ref에 대한 새 파이프라인이 트리거되면 자동으로 취소될 수 있습니다.
  • 다운스트림 프로젝트의 파이프라인 디렉터리에 표시됩니다.
  • 독립적이므로 중첩 제한이 없습니다.

공개 프로젝트를 사용하여 비공개 프로젝트에서 하류 파이프라인을 트리거하려는 경우, 기밀성 문제가 없는지 확인하세요. 상류 프로젝트의 파이프라인 페이지에서는 항상 다음이 표시됩니다:

  • 다운스트림 프로젝트의 이름.
  • 파이프라인의 상태.

.gitlab-ci.yml 파일의 작업에서 하류 파이프라인을 트리거

.gitlab-ci.yml 파일에서 trigger 키워드를 사용하여 하류 파이프라인을 트리거하는 작업을 만듭니다. 이 작업을 트리거 작업이라고 합니다.

예를 들어:

부모-자식 파이프라인
trigger_job:
  trigger:
    include:
      - local: path/to/child-pipeline.yml
다중 프로젝트 파이프라인
trigger_job:
  trigger:
    project: project-group/my-downstream-project

트리거 작업이 시작되면, 작업의 초기 상태가 pending이고 GitLab이 하류 파이프라인을 만들려고 시도하는 동안입니다. 하류 파이프라인이 성공적으로 생성되면 트리거 작업은 passed를 보여주며, 그렇지 않으면 failed를 보여줍니다. 대신에, 트리거 작업이 하류 파이프라인의 상태를 표시하도록 설정할 수도 있습니다.

rules를 사용하여 하류 파이프라인 작업 제어

하류 파이프라인에서 작업 동작을 제어하기 위해 CI/CD 변수나 rules 키워드를 사용하세요.

trigger 키워드를 사용하여 하류 파이프라인을 트리거할 때, 모든 작업에 대한 [$CI_PIPELINE_SOURCE 사전 정의 변수의 값은 다음과 같습니다:

  • 다중 프로젝트 파이프라인의 경우 pipeline.
  • 부모-자식 파이프라인의 경우 parent_pipeline.

예를 들어, Merge Request 파이프라인도 실행하는 프로젝트에서 다중 프로젝트 파이프라인에서 작업을 제어하려면: 

job1:
  rules:
    - if: $CI_PIPELINE_SOURCE == "pipeline"
  script: echo "This job runs in multi-project pipelines only"

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

job3:
  rules:
    - if: $CI_PIPELINE_SOURCE == "pipeline"
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  script: echo "This job runs in both multi-project and merge request pipelines"

다른 프로젝트의 자식 파이프라인 구성 파일 사용

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

다른 프로젝트의 구성 파일을 사용하여 include:project를 트리거 작업에서 사용하여 자식 파이프라인을 트리거할 수 있습니다: 

microservice_a:
  trigger:
    include:
      - project: 'my-group/my-pipeline-library'
        ref: 'main'
        file: '/path/to/child-pipeline.yml'

여러 개의 자식 파이프라인 구성 파일 결합

자식 파이프라인을 정의할 때 최대 세 개의 구성 파일을 포함할 수 있습니다. 자식 파이프라인의 구성은 모든 구성 파일을 합쳐서 구성됩니다: 

microservice_a:
  trigger:
    include:
      - local: path/to/microservice_a.yml
      - template: Jobs/SAST.gitlab-ci.yml
      - project: 'my-group/my-pipeline-library'
        ref: 'main'
        file: '/path/to/child-pipeline.yml'

동적 자식 파이프라인

프로젝트에 저장된 정적 파일이 아닌 작업에서 생성된 YAML 파일에서 자식 파이프라인을 트리거할 수 있습니다. 이 기술은 변경된 콘텐츠를 대상으로 하는 파이프라인을 생성하거나 대상 및 아키텍처의 행렬을 빌드하는 데 매우 강력할 수 있습니다.

생성된 YAML 파일을 포함하는 아티팩트는 5MB보다 크지 않아야 합니다.

개요는 동적으로 생성된 구성을 사용하여 자식 파이프라인 생성을 참조하세요.

동적 자식 파이프라인을 생성하는 예제 프로젝트는 Jsonnet를 사용한 동적 자식 파이프라인를 참조하세요. 이 프로젝트는 데이터 템플릿 언어를 사용하여 런타임에 .gitlab-ci.yml을 생성하는 방법을 보여줍니다. 이러한 유사한 프로세스를 다른 템플릿 언어인 Dhall 또는 ytt에 사용할 수 있습니다.

동적 자식 파이프라인 트리거

동적으로 생성된 구성 파일에서 자식 파이프라인을 트리거하려면:

  1. 작업에서 구성 파일을 생성하고 아티팩트로 저장합니다: 

    generate-config:
  stage: build
  script: generate-ci-config > generated-config.yml
  artifacts:
    paths:
      - generated-config.yml

  2. 트리거된 자식 파이프라인이 실행되도록 트리거 작업을 구성합니다. 생성된 아티팩트에 include: artifact를 설정하고, 아티팩트를 만든 작업에 include: job를 설정합니다: 

    child-pipeline:
  stage: test
  trigger:
    include:
      - artifact: generated-config.yml
        job: generate-config

이 예에서 GitLab은 generated-config.yml을 검색하고 해당 파일의 CI/CD 구성을 사용하여 자식 파이프라인을 트리거합니다.

아티팩트 경로는 실행 중인 OS의 구문과 일치해야 하므로 GitLab이 아닌 러너가 아티팩트 경로를 구문 분석합니다. 예를 들어, GitLab이 Linux에서 실행되지만 Windows 러너를 사용하는 경우 트리거 작업의 경로 구분 기호는 /입니다. 다른 Windows 러너를 사용하는 작업의 CI/CD 구성(스크립트와 같은)은 \를 사용합니다.

Merge Request 파이프라인에서 자식 파이프라인 실행

규칙(rules)이나 workflow:rules을 사용하지 않을 때는 자식 파이프라인을 포함한 모든 파이프라인은 기본적으로 브랜치 파이프라인으로 실행됩니다. 자식 파이프라인을 Merge Request(상위) 파이프라인에서 트리거할 때는 rules 또는 workflow:rules를 사용해야 합니다. 예를 들어, rules를 사용하는 경우:

  1. 상위 파이프라인의 트리거 작업을 Merge Request에서 실행되도록 설정합니다: 

    trigger-child-pipeline-job:
  trigger:
    include: path/to/child-pipeline-configuration.yml
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"

  2. 상위 파이프라인에 의해 트리거된 경우 자식 파이프라인의 작업을 구성하기 위해 rules를 사용합니다: 

    job1:
  script: echo "이 자식 파이프라인 작업은 상위 파이프라인이 트리거될 때 언제나 실행됩니다."
  rules:
    - if: $CI_PIPELINE_SOURCE == "parent_pipeline"
   
job2:
  script: echo "이 자식 파이프라인 작업은 상위 파이프라인이 Merge Request 파이프라인일 때만 실행됩니다."
  rules:
    - if: $CI_MERGE_REQUEST_ID

자식 파이프라인에서 $CI_PIPELINE_SOURCE는 항상 parent_pipeline의 값을 갖기 때문에:

  • if: $CI_PIPELINE_SOURCE == "parent_pipeline"를 사용하여 자식 파이프라인 작업이 항상 실행되도록 설정할 수 있습니다.
  • if: $CI_PIPELINE_SOURCE == "merge_request_event"를 사용하여 Merge Request 파이프라인에 대해 자식 파이프라인 작업을 구성할 수 없습니다. 대신에, if: $CI_MERGE_REQUEST_ID를 사용하여 상위 파이프라인이 Merge Request 파이프라인일 때만 자식 파이프라인 작업을 설정할 수 있습니다. 상위 파이프라인의 CI_MERGE_REQUEST_* 미리 정의된 변수가 자식 파이프라인 작업으로 전달됩니다.

다중 프로젝트 파이프라인의 브랜치 지정

다중 프로젝트 파이프라인을 트리거할 때 사용할 브랜치를 지정할 수 있습니다. GitLab은 브랜치 머리의 커밋을 사용하여 하향 파이프라인을 생성합니다. 예를 들어: 

staging:
  stage: deploy
  trigger:
    project: my/deployment
    branch: stable-11-2

사용:

  • project 키워드를 사용하여 하향 프로젝트의 전체 경로를 지정합니다. GitLab 15.3 이상에서는 변수 확장을 사용할 수 있습니다.
  • branch 키워드를 사용하여 project로 지정된 프로젝트에서 브랜치 또는 태그의 이름을 지정합니다. 변수 확장을 사용할 수 있습니다.

API를 사용하여 다중 프로젝트 파이프라인 트리거

CI/CD 작업 토큰 (CI_JOB_TOKEN)을 파이프라인 트리거 API 엔드포인트와 함께 사용하여 CI/CD 작업 내에서 다중 프로젝트 파이프라인을 트리거할 수 있습니다. GitLab은 작업 토큰으로 트리거된 파이프라인을 API 호출을 한 작업을 포함하는 파이프라인의 하향 파이프라인으로 설정합니다.

예를 들어: 

trigger_pipeline:
  stage: deploy
  script:
    - curl --request POST --form "token=$CI_JOB_TOKEN" --form ref=main "https://gitlab.example.com/api/v4/projects/9/trigger/pipeline"
  rules:
    - if: $CI_COMMIT_TAG
  environment: production

하류 파이프라인 보기

파이프라인 그래프 보기에서 하류 파이프라인은 그래프 오른쪽에 카드 디렉터리으로 표시됩니다. 이 보기에서 다음을 수행할 수 있습니다.

  • 트리거 작업을 선택하여 트리거된 하류 파이프라인의 작업을 볼 수 있습니다.
  • 파이프라인 카드에서 작업 확장 를 선택하여 하류 파이프라인의 작업을 확장하여 볼 수 있습니다. 하류 파이프라인을 한 번에 하나씩 볼 수 있습니다.
  • 파이프라인 카드 위로 호버하여 하류 파이프라인을 트리거한 작업을 강조 표시할 수 있습니다.

하류 파이프라인에서 실패한 작업 및 취소된 작업 다시 시도

  • 그래프 보기에서 재시도는 GitLab 15.0에서 도입되었으며 기본적으로 비활성화된 상태입니다.

실패한 작업 및 취소된 작업을 다시 시도하려면 재시도를 선택하세요():

  • 하류 파이프라인의 세부 페이지에서.
  • 파이프라인 그래프 보기의 파이프라인 카드에서.

하류 파이프라인 재생성

  • 그래프 보기로부터 트리거된 작업에서 재시도가 GitLab 15.10에서 도입되었으며 기본적으로 비활성화된 상태입니다.
  • GitLab 15.11에서 일반적으로 사용 가능하며 ci_recreate_downstream_pipeline 피처 플래그가 제거되었습니다.

하류 파이프라인을 다시 생성할 수 있습니다. 해당 트리거 작업을 다시 시도하여 새로 생성된 하류 파이프라인이 파이프라인 그래프의 현재 하류 파이프라인을 대체합니다.

하류 파이프라인을 다시 만들려면:

  • 파이프라인 그래프 보기의 트리거 작업 카드에서 다시 실행을 선택하세요().

하류 파이프라인 취소

  • 그래프 보기로부터 재시도는 GitLab 15.0에서 도입되었으며 기본적으로 비활성화된 상태입니다.
  • 그래프 보기로부터 재시도는 GitLab 15.1에서 일반적으로 사용 가능하며 피처 플래그가 제거되었습니다.

아직 실행 중인 하류 파이프라인을 취소하려면 실행중인 하류 파이프라인에서 취소를 선택하세요():

  • 하류 파이프라인의 세부 페이지에서.
  • 파이프라인 그래프 보기의 파이프라인 카드에서.

상류 파이프라인에서 하류 파이프라인으로 자동 취소

자식 파이프라인을 구성하여 자동 취소하면 작업 중 하나가 실패하자마자 취소할 수 있습니다.

부모 파이프라인은 다음 경우에만 자동으로 취소됩니다.

  • 부모 파이프라인은 작업 실패 시 자동으로 취소되도록 설정되어 있어야 합니다.
  • 트리거 작업이 strategy: depend로 구성되어 있어야 합니다.

예시:

  • .gitlab-ci.yml 내용: 

    workflow:
  auto_cancel:
    on_job_failure: all
  
trigger_job:
  trigger:
    include: child-pipeline.yml
    strategy: depend
  
job3:
  script:
    - sleep 120

  • child-pipeline.yml 내용 

    # Contents of child-pipeline.yml
workflow:
  auto_cancel:
    on_job_failure: all
  
job1:
  script: sleep 60
  
job2:
  script:
    - sleep 30
    - exit 1

이 예시에서:

  1. 부모 파이프라인은 자식 파이프라인과 job3을 동시에 트리거합니다.
  2. 자식 파이프라인의 job2가 실패하고 자식 파이프라인이 취소되어 job1도 중단됩니다.
  3. 자식 파이프라인이 취소되었으므로 부모 파이프라인이 자동으로 취소됩니다.

트리거 작업에서 하류 파이프라인의 상태를 미러링

트리거 작업에서 strategy: depend를 사용하여 하류 파이프라인의 상태를 미러링할 수 있습니다.

상위-하위 파이프라인
trigger_job:
  trigger:
    include:
      - local: path/to/child-pipeline.yml
    strategy: depend
다중 프로젝트 파이프라인
trigger_job:
  trigger:
    project: my/project
    strategy: depend

파이프라인 그래프에서 다중 프로젝트 파이프라인 보기

다중 프로젝트 파이프라인을 트리거한 후, 하류 파이프라인이 파이프라인 그래프의 오른쪽에 표시됩니다.

파이프라인 미니 그래프에서 하류 파이프라인이 미니 그래프의 오른쪽에 표시됩니다.

상류 파이프라인에서 아티팩트 가져오기

Tier: Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated
상위-하위 파이프라인

needs:pipeline:job를 사용하여 상류 파이프라인에서 아티팩트를 가져올 수 있습니다.

  1. 상류 파이프라인에서 artifacts 키워드가 포함된 작업에서 아티팩트를 저장한 후 해당 아티팩트를 트리거 작업으로 다시 트리거하세요: 

    build_artifacts:
  stage: build
  script:
    - echo "This is a test artifact!" >> artifact.txt
  artifacts:
    paths:
      - artifact.txt
   
deploy:
  stage: deploy
  trigger:
    include:
      - local: path/to/child-pipeline.yml
  variables:
    PARENT_PIPELINE_ID: $CI_PIPELINE_ID

  2. 하류 파이프라인의 작업에서 needs:pipeline:job를 사용하여 아티팩트를 가져옵니다. 

    test:
  stage: test
  script:
    - cat artifact.txt
  needs:
    - pipeline: $PARENT_PIPELINE_ID
      job: build_artifacts

    job을 아티팩트를 생성한 상류 파이프라인의 작업으로 설정하세요.

다중 프로젝트 파이프라인

needs:project를 사용하여 상류 파이프라인에서 아티팩트를 가져올 수 있습니다.

  1. GitLab 15.9 이상에서는 상류 프로젝트를 상류 프로젝트를 작업 토큰 범위 허용 디렉터리에 추가하세요.

  2. 상류 파이프라인에서 artifacts 키워드가 포함된 작업에서 아티팩트를 저장한 후 해당 아티팩트를 트리거 작업으로 다시 트리거하세요: 

    build_artifacts:
  stage: build
  script:
    - echo "This is a test artifact!" >> artifact.txt
  artifacts:
    paths:
      - artifact.txt
   
deploy:
  stage: deploy
  trigger: my/downstream_project   # Path to the project to trigger a pipeline in

  3. 하류 파이프라인의 작업에서 needs:project를 사용하여 아티팩트를 가져옵니다. 

    test:
  stage: test
  script:
    - cat artifact.txt
  needs:
    - project: my/upstream_project
      job: build_artifacts
      ref: main
      artifacts: true

    다음을 설정하세요:

    • 아티팩트를 생성한 상류 파이프라인의 작업을 job으로 설정하세요.
    • 브랜치를 ref로 설정하세요.
    • artifacts를 true로 설정하세요.

상류 Merge Request 파이프라인에서 아티팩트 가져오기

needs:project를 사용하여 아티팩트를 하류 파이프라인에 전달할 때, ref 값은 일반적으로 main 또는 development와 같은 브랜치 이름입니다.

Merge Request 파이프라인의 경우, ref 값은 refs/merge-requests/<id>/head 형식으로 되어 있으며, 여기서 id는 Merge Request ID입니다. 이 ref는 CI_MERGE_REQUEST_REF_PATH CI/CD 변수로 검색할 수 있습니다. Merge Request 파이프라인에서는 브랜치 이름을 ref로 사용하지 마십시오. 왜냐하면 하류 파이프라인이 최신 브랜치 파이프라인에서 아티팩트를 가져오려고 시도하기 때문입니다.

브랜치 파이프라인이 아닌 상류 Merge Request 파이프라인에서 아티팩트를 가져오려면 변수 상속을 사용하여 CI_MERGE_REQUEST_REF_PATH를 하류 파이프라인에 전달하십시오.

  1. GitLab 15.9 이상의 경우, 상류 프로젝트의 작업 토큰 범위 허용 디렉터리에 하류 프로젝트를 추가하십시오. (하향 작업 토큰 범위 허용 디렉터리에 프로젝트 추가).
  2. 상류 파이프라인의 작업에서 artifacts 키워드를 사용하여 아티팩트를 저장하십시오.
  3. 하류 파이프라인을 트리거하는 작업에서 $CI_MERGE_REQUEST_REF_PATH 변수를 전달하십시오: 
build_artifacts:
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
  stage: build
  script:
    - echo "This is a test artifact!" >> artifact.txt
  artifacts:
    paths:
      - artifact.txt

upstream_job:
  rules:
    - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
  variables:
    UPSTREAM_REF: $CI_MERGE_REQUEST_REF_PATH
  trigger:
    project: my/downstream_project
    branch: my-branch
  1. 하류 파이프라인의 작업에서 상류 파이프라인의 아티팩트를 가져오려면, needs:project와 전달된 변수를 ref로 사용하십시오: 
test:
  stage: test
  script:
    - cat artifact.txt
  needs:
    - project: my/upstream_project
      job: build_artifacts
      ref: $UPSTREAM_REF
      artifacts: true

상류 Merge Request 파이프라인에서 아티팩트를 가져오는 데에 이 방법을 사용할 수 있지만, Merge Result 파이프라인에서는 사용할 수 없습니다.

CI/CD 변수를 하류 파이프라인에 전달하기

CI/CD 변수를 상류 파이프라인에서 생성 또는 정의하는 위치에 따라, 다양한 방법으로 하류 파이프라인에 전달할 수 있습니다.

YAML에서 정의된 CI/CD 변수 전달하기

variables 키워드를 사용하여 CI/CD 변수를 하류 파이프라인에 전달할 수 있습니다. 이러한 변수는 변수 우선 순위의 “트리거 변수”로 사용됩니다.

예:

상하위 프로젝트 (Parent-child pipeline)
variables:
  VERSION: "1.0.0"

staging:
  variables:
    ENVIRONMENT: staging
  stage: deploy
  trigger:
    include:
      - local: path/to/child-pipeline.yml
다중 프로젝트 파이프라인 (Multi-project pipeline)
variables:
  VERSION: "1.0.0"

staging:
  variables:
    ENVIRONMENT: staging
  stage: deploy
  trigger: my-group/my-deployment-project

ENVIRONMENT 변수는 하류 파이프라인에 정의된 모든 작업에서 사용할 수 있습니다.

모든 파이프라인의 모든 작업은 전역 variables을 상속하기 때문에 VERSION 전역 변수도 하류 파이프라인에서 사용할 수 있습니다.

전역 변수가 전달되지 않도록 방지하기

inherit:variables:false를 사용하여 전역 CI/CD 변수가 하류 파이프라인에 전달되지 않도록 할 수 있습니다.

예:

상하위 프로젝트 (Parent-child pipeline)
variables:
  GLOBAL_VAR: value

trigger-job:
  inherit:
    variables: false
  variables:
    JOB_VAR: value
  trigger:
    include:
      - local: path/to/child-pipeline.yml
다중 프로젝트 파이프라인 (Multi-project pipeline)
variables:
  GLOBAL_VAR: value

trigger-job:
  inherit:
    variables: false
  variables:
    JOB_VAR: value
  trigger: my-group/my-project

GLOBAL_VAR 변수는 트리거된 파이프라인에서 사용할 수 없지만, JOB_VAR는 사용할 수 있습니다.

사전 정의된 변수 전달하기

사전 정의된 CI/CD 변수를 사용하여 상류 파이프라인에 대한 정보를 하류 파이프라인에 전달하기 위해 보간(interpolation)을 사용합니다. 사전 정의 변수를 새 작업 변수로 저장한 후 이를 하류 파이프라인으로 전달합니다. 예:

상하위 프로젝트 (Parent-child pipeline)
trigger-job:
  variables:
    PARENT_BRANCH: $CI_COMMIT_REF_NAME
  trigger:
    include:
      - local: path/to/child-pipeline.yml
다중 프로젝트 파이프라인 (Multi-project pipeline)
trigger-job:
  variables:
    UPSTREAM_BRANCH: $CI_COMMIT_REF_NAME
  trigger: my-group/my-project

UPSTREAM_BRANCH 변수는 하류 파이프라인에서 사용할 수 있습니다. 이 변수는 상류 파이프라인의 $CI_COMMIT_REF_NAME 사전 정의 CI/CD 변수의 값을 포함합니다.

이러한 방법을 사용하여 마스킹된 변수를 다중 프로젝트 파이프라인에 전달하지 마십시오. CI/CD 마스킹 구성이 하류 파이프라인으로 전달되지 않으며, 변수가 하류 프로젝트의 작업 로그에서 언마스킹될 수 있습니다.

또한, 작업 수준 지속 변수는 트리거 작업에서 사용할 수 없으므로 다중 프로젝트 파이프라인에 전달할 수 없습니다.

상류 파이프라인은 하류 파이프라인보다 우선합니다. 상류 및 하류 프로젝트에서 동일한 이름을 가진 두 변수가 정의된 경우, 상류 프로젝트에서 정의된 변수가 우선합니다.

작업에서 생성된 dotenv 변수 전달하기

Tier: Premium, Ultimate Offering: GitLab.com, 셀프매니지, GitLab Dedicated

작업에서 하류 파이프라인으로 변수를 전달할 수 있습니다. dotenv 변수 상속을 사용하여 이를 수행할 수 있습니다.

예를 들어 다중 프로젝트 파이프라인의 경우:

  1. .env 파일에 변수를 저장하십시오.
  2. .env 파일을 dotenv 보고서로 저장하십시오.
  3. 하류 파이프라인을 트리거하십시오. 
build_vars:
  stage: build
  script:
    - echo "BUILD_VERSION=hello" >> build.env
  artifacts:
    reports:
      dotenv: build.env

deploy:
  stage: deploy
  trigger: my/downstream_project
  1. 하류 프로젝트의 test 작업에서 상류 프로젝트의 build_vars 작업에서 생성된 변수를 상속하여 변수에 접근할 수 있습니다. 
test:
  stage: test
  script:
    - echo $BUILD_VERSION
  needs:
    - project: my/upstream_project
      job: build_vars
      ref: master
      artifacts: true

하류 파이프라인용 배포

하류 파이프라인으로 trigger 키워드를 사용하여 하류 파이프라인으로 전달할 변수의 유형을 지정합니다. 전달된 변수는 트리거 변수로 간주되며, 이는 가장 높은 우선 순위를 갖습니다.

하류 파이프라인은 인프라를 프로비저닝하고 특정 환경에 배포한 후 이를 상류 프로젝트에 배포 상태로 돌려보낼 수 있습니다.

상류 프로젝트로부터 환경 및 배포를 확인할 수 있습니다.

고급 예시

이 예시 구성에는 다음과 같은 동작이 있습니다:

  • 상류 프로젝트가 브랜치 이름을 기반으로 환경 이름을 동적으로 구성합니다.
  • 상류 프로젝트는 UPSTREAM_* 변수를 사용하여 하류 프로젝트로 배포의 컨텍스트를 전달합니다.

상류 프로젝트의 .gitlab-ci.yml: 

stages:
  - deploy
  - cleanup

.downstream-deployment-pipeline:
  variables:
    UPSTREAM_PROJECT_ID: $CI_PROJECT_ID
    UPSTREAM_ENVIRONMENT_NAME: $CI_ENVIRONMENT_NAME
    UPSTREAM_ENVIRONMENT_ACTION: $CI_ENVIRONMENT_ACTION
  trigger:
    project: project-group/deployment-project
    branch: main
    strategy: depend

deploy-review:
  stage: deploy
  extends: .downstream-deployment-pipeline
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    on_stop: stop-review

stop-review:
  stage: cleanup
  extends: .downstream-deployment-pipeline
  environment:
    name: review/$CI_COMMIT_REF_SLUG
    action: stop
  when: manual

하류 프로젝트의 .gitlab-ci.yml: 

deploy:
  script: echo "${UPSTREAM_PROJECT_ID}에 대한 ${UPSTREAM_ENVIRONMENT_NAME}로 배포"
  rules:
    - if: $CI_PIPELINE_SOURCE == "pipeline" && $UPSTREAM_ENVIRONMENT_ACTION == "start"

stop:
  script: echo "${UPSTREAM_PROJECT_ID}에 대한 ${UPSTREAM_ENVIRONMENT_NAME} 중지"
  rules:
    - if: $CI_PIPELINE_SOURCE == "pipeline" && $UPSTREAM_ENVIRONMENT_ACTION == "stop"

문제 해결

트리거 작업이 실패하고 다중 프로젝트 파이프라인이 생성되지 않음

다중 프로젝트 파이프라인의 경우, 트리거 작업이 실패하고 하류 파이프라인이 생성되지 않는 경우:

  • 하류 프로젝트를 찾을 수 없음.
  • 상류 파이프라인을 생성하는 사용자에게 권한이 없음.
  • 하류 파이프라인이 보호된 브랜치를 대상으로 하며 사용자에게 보호된 브랜치에 대한 파이프라인 실행 권한이 없음. 자세한 내용은 보호된 브랜치에 대한 파이프라인 보안을 참조하십시오.

다운스트림 프로젝트에서 권한 문제를 겪는 사용자를 확인하려면 다음 명령을 사용하여 트리거 작업을 확인하고 user_id 속성을 확인하십시오. 

Ci::Bridge.find(<작업_ID>)

자식 파이프라인의 작업이 실행되지 않음

상위 파이프라인이 Merge Request 파이프라인인 경우, 자식 파이프라인은 작업 실행을 보장하기 위해 workflow:rules 또는 rules를 사용해야 합니다.

자식 파이프라인의 작업 중 하나라도 실행할 수 없는 경우:

  • 자식 파이프라인이 시작되지 않음.
  • 상위 파이프라인의 트리거 작업이 다음과 같은 오류로 실패함: 다운스트림 파이프라인을 생성할 수 없으며 선택한 트리거에 대한 파이프라인이 실행되지 않습니다. 규칙 구성으로 인해 파이프라인에 작업이 추가되지 않았습니다.

Ref is ambiguous

동일한 이름의 브랜치가 있는 경우 태그로 다중 프로젝트 파이프라인을 트리거할 수 없습니다. 동일한 이름의 브랜치와 태그가 있는 경우 다운스트림 파이프라인 생성이 실패하며 Ref is ambiguous 오류가 발생합니다.

태그 이름이 브랜치 이름과 일치하지 않는 태그로만 다중 프로젝트 파이프라인을 트리거하세요.

상류 파이프라인에서 작업 아티팩트 다운로드 시 403 Forbidden 오류

GitLab 15.9 이상에서 CI/CD 작업 토큰은 파이프라인이 실행되는 프로젝트에 대해 범위가 지정됩니다. 따라서 하류 파이프라인의 작업 토큰으로 상류 프로젝트에 액세스할 수 없습니다.

이를 해결하려면 하류 프로젝트를 작업 토큰 범위 허용 디렉터리에 추가하십시오.