다운스트림 파이프라인은 다른 파이프라인에 의해 트리거된 GitLab CI/CD 파이프라인입니다. 다운스트림 파이프라인은 트리거한 업스트림 파이프라인과 독립적으로 동시에 실행됩니다.

• 부모-자식 파이프라인은 첫 번째 파이프라인과 동일한 프로젝트에서 트리거되는 다운스트림 파이프라인입니다.
• 멀티 프로젝트 파이프라인은 첫 번째 파이프라인과 다른 프로젝트에서 트리거되는 다운스트림 파이프라인입니다.

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

파이프라인 계층에는 기본적으로 최대 1000개의 다운스트림 파이프라인이 포함될 수 있습니다. 이 제한 및 변경 방법에 대한 자세한 내용은 파이프라인 계층 크기 제한을 참조하세요.

부모-자식 파이프라인#

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

자식 파이프라인:

• 부모 파이프라인과 동일한 프로젝트, ref, 커밋 SHA에서 실행됩니다.
• 파이프라인이 실행되는 ref의 전체 상태에 직접적인 영향을 주지 않습니다. 예를 들어 main 브랜치에서 파이프라인이 실패하면 "main이 broken 상태"라고 말하는 경우가 많습니다. 자식 파이프라인의 상태는 자식 파이프라인이 trigger:strategy로 트리거된 경우에만 ref의 상태에 영향을 줍니다.
• 파이프라인이 interruptible로 구성된 경우 동일한 ref에 대해 새 파이프라인이 생성될 때 자동으로 취소됩니다.
• 프로젝트의 파이프라인 목록에 표시되지 않습니다. 자식 파이프라인은 부모 파이프라인의 세부 정보 페이지에서만 볼 수 있습니다.

중첩 자식 파이프라인#

부모 파이프라인과 자식 파이프라인은 최대 두 단계의 자식 파이프라인 깊이를 가집니다.

부모 파이프라인은 많은 자식 파이프라인을 트리거할 수 있으며, 이 자식 파이프라인들도 자체 자식 파이프라인을 트리거할 수 있습니다. 또 다른 단계의 자식 파이프라인은 트리거할 수 없습니다.

개요를 보려면 중첩 동적 파이프라인을 참조하세요.

멀티 프로젝트 파이프라인#

한 프로젝트의 파이프라인은 다른 프로젝트에서 멀티 프로젝트 파이프라인이라고 하는 다운스트림 파이프라인을 트리거할 수 있습니다. 업스트림 파이프라인을 트리거하는 사용자는 다운스트림 프로젝트에서 파이프라인을 시작할 수 있어야 합니다. 그렇지 않으면 다운스트림 파이프라인이 시작에 실패합니다.

멀티 프로젝트 파이프라인:

• 다른 프로젝트의 파이프라인에서 트리거되지만, 업스트림(트리거) 파이프라인은 다운스트림(트리거된) 파이프라인에 대한 제어가 많지 않습니다. 그러나 다운스트림 파이프라인의 ref를 선택하고 CI/CD 변수를 전달할 수 있습니다.
• 실행되는 프로젝트의 ref 전체 상태에 영향을 주지만 trigger:strategy로 트리거되지 않는 한 트리거 파이프라인의 ref 상태에는 영향을 주지 않습니다.
• 업스트림 파이프라인에서 동일한 ref에 대해 새 파이프라인이 실행될 때 interruptible을 사용하면 다운스트림 프로젝트에서 자동으로 취소되지 않습니다. 다운스트림 프로젝트의 동일한 ref에 대해 새 파이프라인이 트리거되면 자동으로 취소될 수 있습니다.
• 다운스트림 프로젝트의 파이프라인 목록에 표시됩니다.
• 독립적이므로 중첩 제한이 없습니다.

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

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

.gitlab-ci.yml 파일의 job에서 다운스트림 파이프라인 트리거#

.gitlab-ci.yml 파일에서 trigger 키워드를 사용하여 다운스트림 파이프라인을 트리거하는 job을 생성합니다. 이 job을 트리거 job이라고 합니다.

예를 들어:

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

trigger_job:
  trigger:
    project: project-group/my-downstream-project

트리거 job이 시작되면 GitLab이 다운스트림 파이프라인을 생성하려고 시도하는 동안 job의 초기 상태는 pending입니다. 다운스트림 파이프라인이 성공적으로 생성되면 트리거 job은 passed를 표시하고, 그렇지 않으면 failed를 표시합니다. 또는 트리거 job이 다운스트림 파이프라인의 상태를 표시하도록 설정할 수 있습니다.

rules를 사용하여 다운스트림 파이프라인 job 제어#

CI/CD 변수 또는 rules 키워드를 사용하여 다운스트림 파이프라인에서 job 동작을 제어합니다.

trigger 키워드로 다운스트림 파이프라인을 트리거할 때, 모든 job의 $CI_PIPELINE_SOURCE 사전 정의 변수 값은:

• 멀티 프로젝트 파이프라인의 경우 pipeline
• 부모-자식 파이프라인의 경우 parent_pipeline

예를 들어, 머지 리퀘스트 파이프라인도 실행하는 프로젝트의 멀티 프로젝트 파이프라인에서 job을 제어하려면:

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"

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

트리거 job에서 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'

동적 자식 파이프라인#

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

생성된 YAML 파일을 포함하는 아티팩트는 인스턴스 제한 내에 있어야 합니다.

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

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

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

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

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

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

2. 구성 파일을 생성한 job 다음에 실행되도록 트리거 job을 구성합니다. include: artifact를 생성된 아티팩트로 설정하고, include: job을 아티팩트를 만든 job으로 설정합니다:

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

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

아티팩트 경로는 러너가 아닌 GitLab에서 파싱하므로 경로는 GitLab이 실행 중인 OS의 구문과 일치해야 합니다. GitLab이 Linux에서 실행 중이지만 테스트에 Windows 러너를 사용하는 경우 트리거 job의 경로 구분자는 /입니다. Windows 러너를 사용하는 job의 다른 CI/CD 구성(예: 스크립트)은 \를 사용합니다.

동적 자식 파이프라인의 구성에서 include 섹션에 CI/CD 변수를 사용할 수 없습니다.

머지 리퀘스트 파이프라인으로 자식 파이프라인 실행#

파이프라인(자식 파이프라인 포함)은 rules 또는 workflow:rules를 사용하지 않을 때 기본적으로 브랜치 파이프라인으로 실행됩니다. 머지 리퀘스트(부모) 파이프라인에서 트리거될 때 자식 파이프라인이 실행되도록 구성하려면 rules 또는 workflow:rules를 사용합니다. 예를 들어, rules를 사용하는 경우:

1. 머지 리퀘스트에서 실행되도록 부모 파이프라인의 트리거 job을 설정합니다:

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

2. rules를 사용하여 부모 파이프라인에 의해 트리거될 때 자식 파이프라인 job이 실행되도록 구성합니다:

   job1:
     script: echo "This child pipeline job runs any time the parent pipeline triggers it."
     rules:
       - if: $CI_PIPELINE_SOURCE == "parent_pipeline"
   
   job2:
     script: echo "This child pipeline job runs only when the parent pipeline is a merge request pipeline"
     rules:
       - if: $CI_MERGE_REQUEST_ID
   

자식 파이프라인에서 $CI_PIPELINE_SOURCE는 항상 parent_pipeline 값을 가지므로:

• if: $CI_PIPELINE_SOURCE == "parent_pipeline"을 사용하여 자식 파이프라인 job이 항상 실행되도록 할 수 있습니다.
• 머지 리퀘스트 파이프라인에 대해 자식 파이프라인 job을 실행하도록 구성하는 데 if: $CI_PIPELINE_SOURCE == "merge_request_event"를 사용할 수 없습니다. 대신 부모 파이프라인이 머지 리퀘스트 파이프라인인 경우에만 자식 파이프라인 job이 실행되도록 설정하려면 if: $CI_MERGE_REQUEST_ID를 사용합니다. 부모 파이프라인의 CI_MERGE_REQUEST_* 사전 정의 변수가 자식 파이프라인 job에 전달됩니다.

멀티 프로젝트 파이프라인의 브랜치 지정#

멀티 프로젝트 파이프라인을 트리거할 때 사용할 브랜치를 지정할 수 있습니다. GitLab은 브랜치의 헤드에 있는 커밋을 사용하여 다운스트림 파이프라인을 생성합니다. 예를 들어:

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

사용:

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

API를 사용하여 멀티 프로젝트 파이프라인 트리거#

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

예를 들어:

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

다운스트림 파이프라인 보기#

파이프라인 세부 정보 페이지에서 다운스트림 파이프라인은 그래프 오른쪽에 카드 목록으로 표시됩니다. 이 뷰에서 다음을 수행할 수 있습니다:

• 트리거 job을 선택하여 트리거된 다운스트림 파이프라인의 job을 봅니다.
• 파이프라인 카드에서 job 확장 [chevron-lg-right]을 선택하여 다운스트림 파이프라인의 job으로 뷰를 확장합니다. 한 번에 하나의 다운스트림 파이프라인만 볼 수 있습니다.
• 파이프라인 카드 위로 마우스를 이동하면 다운스트림 파이프라인을 트리거한 job이 강조 표시됩니다.

다운스트림 파이프라인에서 실패하고 취소된 job 재시도#

실패하고 취소된 job을 재시도하려면 재시도 ([retry])를 선택합니다:

• 다운스트림 파이프라인의 세부 정보 페이지에서
• 파이프라인 그래프 뷰의 파이프라인 카드에서

다운스트림 파이프라인 다시 만들기#

해당 트리거 job을 재시도하여 다운스트림 파이프라인을 다시 만들 수 있습니다. 새로 생성된 다운스트림 파이프라인은 파이프라인 그래프의 현재 다운스트림 파이프라인을 교체합니다.

다운스트림 파이프라인을 다시 만들려면:

• 파이프라인 그래프 뷰의 트리거 job 카드에서 다시 실행 ([retry])을 선택합니다.

다운스트림 파이프라인 취소#

아직 실행 중인 다운스트림 파이프라인을 취소하려면 취소 ([cancel])를 선택합니다:

• 다운스트림 파이프라인의 세부 정보 페이지에서
• 파이프라인 그래프 뷰의 파이프라인 카드에서

다운스트림 파이프라인에서 부모 파이프라인 자동 취소#

자식 파이프라인의 job 중 하나가 실패하는 즉시 자식 파이프라인을 자동 취소하도록 구성할 수 있습니다.

부모 파이프라인은 다음 경우에만 자식 파이프라인의 job 실패 시 자동 취소됩니다:

• 부모 파이프라인도 job 실패 시 자동 취소하도록 설정되어 있습니다.
• 트리거 job이 strategy: mirror로 구성되어 있습니다.

예를 들어:

• .gitlab-ci.yml 내용:

  workflow:
    auto_cancel:
      on_job_failure: all
  
  trigger_job:
    trigger:
      include: child-pipeline.yml
      strategy: mirror
  
  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. 자식 파이프라인이 취소되었으므로 부모 파이프라인이 자동 취소됩니다.

트리거 job에서 다운스트림 파이프라인 상태 미러링#

trigger: strategy를 사용하여 트리거 job에서 다운스트림 파이프라인의 상태를 미러링할 수 있습니다:

strategy: mirror를 사용하면 트리거 job은 항상 다운스트림 파이프라인과 동일한 상태를 가집니다.

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

trigger_job:
  trigger:
    project: my/project
    strategy: mirror

strategy: depend는 트리거 job 상태가 다운스트림 파이프라인의 상태와 항상 일치하지 않으므로 권장하지 않습니다. trigger:strategy 참조의 추가 세부 정보를 참조하세요.

파이프라인 그래프에서 멀티 프로젝트 파이프라인 보기#

멀티 프로젝트 파이프라인을 트리거한 후 다운스트림 파이프라인은 파이프라인 그래프 오른쪽에 표시됩니다.

파이프라인 미니 그래프에서 다운스트림 파이프라인은 미니 그래프 오른쪽에 표시됩니다.

머지 리퀘스트에서 자식 파이프라인 보고서 보기#

머지 리퀘스트 위젯에서 자식 파이프라인의 보고서를 보고 다운로드할 수 있습니다. 이를 통해 여러 파이프라인을 수동으로 탐색하지 않고도 파이프라인 계층 전반에 걸친 테스트 결과와 품질 검사에 대한 통합 뷰를 제공합니다.

자식 파이프라인에서 지원되는 보고서 유형은 다음과 같습니다:

• 단위 테스트 보고서 (JUnit)
• 코드 품질 보고서
• Terraform 보고서
• 메트릭 보고서
• 보안 보고서 (SAST, secret detection, dependency scanning, container scanning, DAST, API fuzzing)

보안 보고서는 동일한 프로젝트의 자식 파이프라인, 동적으로 생성된 자식 파이프라인, 파이프라인 실행 정책에 의해 생성된 파이프라인에서 작동합니다. 스캔 실행 정책의 보고서는 지원되지 않습니다.

자식 파이프라인의 테스트 결과와 보안 발견은 부모 파이프라인의 Tests 및 Security 탭에도 표시됩니다.

자식 파이프라인 보안 발견은 머지 리퀘스트 승인 정책을 트리거할 수 있습니다. 자식 파이프라인이 취약점을 감지하면 머지하기 전에 추가 승인이 필요할 수 있습니다.

아티팩트 보고서를 생성하는 자식 파이프라인에 대해 머지 리퀘스트 위젯에 자식 파이프라인의 보고서가 표시되도록 하려면 strategy: depend 또는 strategy: mirror를 사용합니다. 예를 들어:

test-backend:
  trigger:
    include: backend-tests.yml
    strategy: depend

test-frontend:
  trigger:
    include: frontend-tests.yml
    strategy: depend

이러한 전략 없이는 자식 파이프라인이 완료되기 전에 부모 파이프라인이 완료되어 머지 리퀘스트에 보고서가 표시되지 않습니다.

업스트림 파이프라인에서 아티팩트 가져오기#

업스트림 머지 리퀘스트 파이프라인에서 아티팩트 가져오기#

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

머지 리퀘스트 파이프라인의 경우 ref 값은 refs/merge-requests/<id>/head 형식입니다. 여기서 id는 머지 리퀘스트 ID입니다. CI_MERGE_REQUEST_REF_PATH CI/CD 변수로 이 ref를 검색할 수 있습니다. 머지 리퀘스트 파이프라인에서 ref로 브랜치 이름을 사용하지 마세요. 다운스트림 파이프라인이 최신 브랜치 파이프라인에서 아티팩트를 가져오려고 시도하기 때문입니다.

branch 파이프라인 대신 업스트림 머지 리퀘스트 파이프라인에서 아티팩트를 가져오려면, 변수 상속을 사용하여 CI_MERGE_REQUEST_REF_PATH를 다운스트림 파이프라인에 전달합니다:

1. GitLab 15.9 이상에서 업스트림 프로젝트의 job 토큰 범위 허용 목록에 다운스트림 프로젝트를 추가합니다.

2. 업스트림 파이프라인의 job에서 artifacts 키워드를 사용하여 아티팩트를 저장합니다.

3. 다운스트림 파이프라인을 트리거하는 job에서 $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
   

4. 다운스트림 파이프라인의 job에서 needs:project와 전달된 변수를 ref로 사용하여 업스트림 파이프라인에서 아티팩트를 가져옵니다:

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

이 방법을 사용하여 업스트림 머지 리퀘스트 파이프라인에서 아티팩트를 가져올 수 있지만, 머지 결과 파이프라인에서는 가져올 수 없습니다.

다운스트림 파이프라인에 입력 전달#

inputs 키워드를 사용하여 다운스트림 파이프라인에 입력 값을 전달할 수 있습니다. 입력은 타입 검사, 옵션을 통한 유효성 검사, 설명, 기본값 등 변수에 비해 이점을 제공합니다.

먼저 spec:inputs를 사용하여 대상 구성 파일에서 입력 매개변수를 정의합니다:

# Target pipeline configuration
spec:
  inputs:
    environment:
      description: "Deployment environment"
      options: [staging, production]
    version:
      type: string
      description: "Application version"

그런 다음 파이프라인을 트리거할 때 값을 제공합니다:

staging:
  trigger:
    include:
      - local: path/to/child-pipeline.yml
        inputs:
          environment: staging
          version: "1.0.0"

staging:
  trigger:
    project: my-group/my-deployment-project
    inputs:
      environment: staging
      version: "1.0.0"

다운스트림 파이프라인에 CI/CD 변수 전달#

변수가 생성되거나 정의된 위치에 따라 다양한 방법으로 다운스트림 파이프라인에 CI/CD 변수를 전달할 수 있습니다.

YAML로 정의된 CI/CD 변수 전달#

variables 키워드를 사용하여 다운스트림 파이프라인에 CI/CD 변수를 전달할 수 있습니다. 이러한 변수는 변수 우선순위에 대한 파이프라인 변수입니다.

예를 들어:

variables:
  VERSION: "1.0.0"

staging:
  variables:
    ENVIRONMENT: staging
  stage: deploy
  trigger:
    include:
      - local: path/to/child-pipeline.yml

variables:
  VERSION: "1.0.0"

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

ENVIRONMENT 변수는 다운스트림 파이프라인에 정의된 모든 job에서 사용할 수 있습니다.

VERSION 기본 변수는 파이프라인의 모든 job(트리거 job 포함)이 기본 variables를 상속하기 때문에 다운스트림 파이프라인에서도 사용할 수 있습니다.

기본 변수가 전달되는 것을 방지#

inherit:variables를 사용하여 기본 CI/CD 변수가 다운스트림 파이프라인에 도달하는 것을 막을 수 있습니다. 상속할 특정 변수를 나열하거나 모든 기본 변수를 차단할 수 있습니다.

예를 들어:

variables:
  DEFAULT_VAR: value

trigger-job:
  inherit:
    variables: false
  variables:
    JOB_VAR: value
  trigger:
    include:
      - local: path/to/child-pipeline.yml

variables:
  DEFAULT_VAR: value

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

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

사전 정의 변수 전달#

사전 정의 CI/CD 변수를 사용하여 업스트림 파이프라인에 대한 정보를 전달하려면 보간을 사용합니다. 사전 정의 변수를 트리거 job의 새 job 변수로 저장하면 다운스트림 파이프라인에 전달됩니다. 예를 들어:

trigger-job:
  variables:
    PARENT_BRANCH: $CI_COMMIT_REF_NAME
  trigger:
    include:
      - local: path/to/child-pipeline.yml

trigger-job:
  variables:
    UPSTREAM_BRANCH: $CI_COMMIT_REF_NAME
  trigger: my-group/my-project

업스트림 파이프라인의 $CI_COMMIT_REF_NAME 사전 정의 CI/CD 변수 값을 포함하는 UPSTREAM_BRANCH 변수를 다운스트림 파이프라인에서 사용할 수 있습니다.

이 방법을 사용하여 멀티 프로젝트 파이프라인에 마스크된 변수를 전달하지 마세요. CI/CD 마스킹 구성은 다운스트림 파이프라인으로 전달되지 않으며 변수가 다운스트림 프로젝트의 job 로그에서 마스크 해제될 수 있습니다.

이 방법을 사용하여 job 전용 변수를 다운스트림 파이프라인에 전달할 수 없습니다. 트리거 job에서 사용할 수 없기 때문입니다.

업스트림 파이프라인은 다운스트림 파이프라인보다 우선합니다. 업스트림 및 다운스트림 프로젝트 모두에 동일한 이름의 두 변수가 정의된 경우, 업스트림 프로젝트에서 정의된 변수가 우선합니다.

job에서 생성된 dotenv 변수 전달#

dotenv 변수 상속을 사용하여 다운스트림 파이프라인에 변수를 전달할 수 있습니다.

다운스트림 파이프라인에 전달할 변수 유형 제어#

trigger:forward 키워드를 사용하여 다운스트림 파이프라인에 전달할 변수 유형을 지정합니다. 전달된 변수는 가장 높은 우선순위를 가진 트리거 변수로 간주됩니다.

배포를 위한 다운스트림 파이프라인#

trigger와 함께 environment 키워드를 사용할 수 있습니다. 배포 및 애플리케이션 프로젝트가 별도로 관리되는 경우 트리거 job에서 environment를 사용하고 싶을 수 있습니다.

deploy:
  trigger:
    project: project-group/my-downstream-project
  environment: production

다운스트림 파이프라인은 인프라를 프로비저닝하고, 지정된 환경에 배포하고, 배포 상태를 업스트림 프로젝트에 반환할 수 있습니다.

업스트림 프로젝트에서 환경 및 배포를 볼 수 있습니다.

고급 예제#

이 예제 구성에는 다음 동작이 있습니다:

• 업스트림 프로젝트는 브랜치 이름을 기반으로 환경 이름을 동적으로 구성합니다.
• 업스트림 프로젝트는 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: mirror

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 "Deploy to ${UPSTREAM_ENVIRONMENT_NAME} for ${UPSTREAM_PROJECT_ID}"
  rules:
    - if: $CI_PIPELINE_SOURCE == "pipeline" && $UPSTREAM_ENVIRONMENT_ACTION == "start"

stop:
  script: echo "Stop ${UPSTREAM_ENVIRONMENT_NAME} for ${UPSTREAM_PROJECT_ID}"
  rules:
    - if: $CI_PIPELINE_SOURCE == "pipeline" && $UPSTREAM_ENVIRONMENT_ACTION == "stop"