다운스트림 파이프라인

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

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

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

부모-자식 파이프라인

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

자식 파이프라인:

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

중첩 자식 파이프라인

부모 및 자식 파이프라인은 자식 파이프라인의 최대 깊이가 두 수준입니다.

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


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

다중 프로젝트 파이프라인

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

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

  • 다른 프로젝트의 파이프라인에서 트리거되지만, 업스트림(트리거) 파이프라인은 다운스트림(트리거된) 파이프라인에 대한 제어가 많지 않습니다. 하지만, 다운스트림 파이프라인의 ref를 선택하고 CI/CD 변수를 전달할 수 있습니다.
  • 파이프라인이 실행되는 프로젝트의 ref의 전체 상태에 영향을 미치지만, 트리거된 파이프라인의 ref의 상태에는 영향을 미치지 않습니다. 단, strategy:depend로 트리거된 경우는 제외입니다.
  • 업스트림 파이프라인에서 동일한 ref에 대해 새 파이프라인이 실행될 때, interruptible를 사용할 경우 다운스트림 프로젝트에서 자동으로 취소되지 않습니다.
    다운스트림 프로젝트에 대해 동일한 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.

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

job1:
  rules:
    - if: $CI_PIPELINE_SOURCE == "pipeline"
  script: echo "이 작업은 다중 프로젝트 파이프라인에서만 실행됩니다."

job2:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  script: echo "이 작업은 머지 요청 파이프라인에서만 실행됩니다."

job3:
  rules:
    - if: $CI_PIPELINE_SOURCE == "pipeline"
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
  script: echo "이 작업은 다중 프로젝트와 머지 요청 파이프라인 모두에서 실행됩니다."

다른 프로젝트에서 하위 파이프라인 구성 파일 사용하기

트리거 작업에서 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를 초과해서는 안 됩니다.

개요를 보려면 동적으로 생성된 구성으로 하위 파이프라인 생성하기를 참조하세요.

동적 하위 파이프라인을 생성하는 예제 프로젝트는 Dynamic Child Pipelines with 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 구성으로 자식 파이프라인을 트리거합니다.

아티팩트 경로는 GitLab에 의해 구문 분석되므로, 경로는 GitLab이 실행되는 OS의 구문과 일치해야 합니다. GitLab이 Linux에서 실행되지만 Windows 러너를 사용하여 테스트하는 경우, 트리거 작업의 경로 구분자는 /입니다. Windows 러너를 사용하는 작업의 다른 CI/CD 구성에서는 \를 사용합니다.

동적 자식 파이프라인의 구성에서 include 섹션에 CI/CD 변수를 사용할 수 없습니다. 문제 378717에서 이 문제를 해결할 것을 제안합니다.

병합 요청 파이프라인으로 자식 파이프라인 실행

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

  1. 부모 파이프라인의 트리거 작업을 병합 요청에서 실행되도록 설정합니다:

    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 "이 자식 파이프라인 작업은 부모 파이프라인이 병합 요청 파이프라인일 때만 실행됩니다."
  rules:
    - if: $CI_MERGE_REQUEST_ID

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

  • 자식 파이프라인 작업이 항상 실행되도록 보장하기 위해 if: $CI_PIPELINE_SOURCE == "parent_pipeline"을 사용할 수 있습니다.
  • 자식 파이프라인 작업을 병합 요청 파이프라인에서 실행되도록 설정하는 if: $CI_PIPELINE_SOURCE == "merge_request_event"를 사용할 수 없습니다. 대신 if: $CI_MERGE_REQUEST_ID를 사용하여 부모 파이프라인이 병합 요청 파이프라인일 때만 자식 파이프라인 작업을 실행하도록 설정합니다. 부모 파이프라인의 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.10에서
    ci_recreate_downstream_pipeline이라는 플래그와 함께. 기본적으로 비활성화됨.
  • GitLab 15.11에서 일반적으로 사용 가능.
    기능 플래그 ci_recreate_downstream_pipeline이 제거됨.

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

하류 파이프라인을 재생성하려면:

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

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

실행 중인 다운스트림 파이프라인을 취소하려면 Cancel ( )을 선택하세요:

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

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

하위 파이프라인을 자동 취소하도록 구성할 수 있습니다.

하위 파이프라인의 작업 중 하나가 실패하면 부모 파이프라인이 자동으로 취소됩니다.

단, 부모 파이프라인은 하위 파이프라인의 작업이 실패할 때만 자동으로 취소됩니다:

  • 부모 파이프라인도 작업 실패 시 자동으로 취소되도록 설정되어 있어야 합니다.
  • 트리거 작업이 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의 내용:

    # 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

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

  • GitLab 16.8에서 GitLab Premium에서 GitLab Free로 이동됨.

다중 프로젝트 파이프라인을 트리거하면 다운스트림 파이프라인이 파이프라인 그래프의 오른쪽에 표시됩니다.

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

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

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   # 파이프라인을 트리거할 프로젝트 경로

  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로 설정합니다.

업스트림 병합 요청 파이프라인에서 아티팩트 가져오기

needs:project를 사용하여 다운스트림 파이프라인으로 아티팩트를 전달할 때,

ref값은 보통 main 또는 development와 같은 브랜치 이름입니다.

병합 요청 파이프라인의 경우, ref 값은 refs/merge-requests/<id>/head 형식이며,

여기서 id는 병합 요청 ID입니다. 이 참조는 CI_MERGE_REQUEST_REF_PATH CI/CD 변수를 사용하여 가져올 수 있습니다.

병합 요청 파이프라인에서는 브랜치 이름을 ref로 사용하지 마세요.

왜냐하면 다운스트림 파이프라인이 최신 브랜치 파이프라인에서 아티팩트를 가져오려고 시도하기 때문입니다.

업스트림 merge request 파이프라인에서 branch 파이프라인 대신 아티팩트를 가져오려면,

변수 상속을 사용하여 다운스트림 파이프라인에 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

  4. 다운스트림 파이프라인의 작업에서 needs:project와 전달된 변수를 ref로 사용하여

    업스트림 파이프라인에서 아티팩트를 가져오세요:

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

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

CI/CD 변수를 다운스트림 파이프라인으로 전달하기

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 변수는 다운스트림 파이프라인에서 정의된 모든 작업에서 사용 가능합니다.

VERSION 전역 변수도 다운스트림 파이프라인에서 사용 가능하며,

파이프라인의 모든 작업(트리거 작업 포함)은 전역 variables를 상속받기 때문입니다.

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

글로벌 CI/CD 변수가 하위 파이프라인에 도달하는 것을 막으려면 inherit:variables:false를 사용하세요.

예를 들어:

부모-자식 파이프라인
variables:
  GLOBAL_VAR: value

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

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

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

미리 정의된 변수 전달

미리 정의된 CI/CD 변수를 사용하여 상위 파이프라인에 대한 정보를 전달하려면 상호 참조를 사용하세요. 미리 정의된 변수를 트리거 작업의 새로운 작업 변수로 저장하면 하위 파이프라인에 전달됩니다. 예를 들어:

부모-자식 파이프라인
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 마스킹 구성은 하위 파이프라인에 전달되지 않으며, 해당 변수는 하위 프로젝트의 작업 로그에서 마스킹 해제될 수 있습니다.

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

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

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

Tier: Premium, Ultimate Offering: GitLab.com, Self-managed, 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

  4. 하위 파이프라인의 test 작업에서 needs를 사용하여 상위 프로젝트의 build_vars 작업에서 변수를 상속하도록 설정합니다. test 작업은 dotenv 보고서의 변수를 상속받으며 스크립트에서 BUILD_VERSION에 접근할 수 있습니다:

    test:
  stage: test
  script:
    - echo $BUILD_VERSION
  needs:
    - project: my/upstream_project
      job: build_vars
      ref: master
      artifacts: true

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

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

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

environment 키워드를 trigger와 함께 사용할 수 있습니다.
배포 및 애플리케이션 프로젝트가 별도로 관리되는 경우, 트리거 작업에서 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: 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 "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"