- 상위-하위 파이프라인
- 다중 프로젝트 파이프라인
-
.gitlab-ci.yml
파일에서 작업을 사용하여 하류 파이프라인 트리거하기 - API를 사용하여 다중 프로젝트 파이프라인 트리거
- 하류 파이프라인 보기
- 상위스트림 파이프라인에서 아티팩트 가져오기
- 다운스트림 파이프라인에 CI/CD 변수 전달하기
- 배포를 위한 다운스트림 파이프라인
- 문제 해결
하류 파이프라인
하류 파이프라인은 다른 파이프라인에 의해 트리거된 GitLab CI/CD 파이프라인입니다.
하류 파이프라인은 트리거한 상류 파이프라인과 독립적으로, 동시에 실행됩니다.
- 상위-하위 파이프라인은 첫 번째 파이프라인과 동일한 프로젝트에서 트리거된 하류 파이프라인입니다.
- 다중 프로젝트 파이프라인은 첫 번째 파이프라인이 있는 다른 프로젝트에서 트리거된 하류 파이프라인입니다.
가끔 상위-하위 파이프라인과 다중 프로젝트 파이프라인을 유사한 목적으로 사용할 수 있지만, 중요한 차이점이 있습니다.
상위-하위 파이프라인
상위 파이프라인은 동일한 프로젝트에서 하류 파이프라인을 트리거하는 파이프라인입니다.
하류 파이프라인은 자식 파이프라인이라고 합니다.
자식 파이프라인:
- 상위 파이프라인과 동일한 프로젝트, 참조, 커밋 SHA에서 실행됩니다.
- 파이프라인이 실행 중인 참조의 전체 상태에 직접적인 영향을 미치지 않습니다. 예를 들어, 메인 브랜치에 대한 파이프라인이 실패하면 “메인이 망가졌다”고 말하는 것이 일반적입니다. 자식 파이프라인의 상태는 자식 파이프라인이
strategy:depend
로 트리거된 경우에만 참조의 상태에 영향을 줍니다. - 동일한 참조에 대한 새로운 파이프라인이 생성될 때
interruptible
로 구성된 경우, 자동으로 취소됩니다. - 프로젝트의 파이프라인 목록에 표시되지 않습니다. 자식 파이프라인은 상위 파이프라인의 세부 정보 페이지에서만 볼 수 있습니다.
중첩된 자식 파이프라인
- GitLab 13.4에서 도입됨.
- GitLab 13.5에서 기능 플래그가 제거되었습니다.
상위 및 하위 파이프라인의 최대 깊이는 두 수준의 자식 파이프라인입니다.
상위 파이프라인은 많은 수의 하위 파이프라인을 트리거할 수 있으며, 이러한 하위 파이프라인은 자체의 하위 파이프라인을 트리거할 수 있습니다. 다른 수준의 자식 파이프라인을 트리거할 수는 없습니다.
개요는 중첩된 동적 파이프라인을 확인하세요.
다중 프로젝트 파이프라인
한 프로젝트에서 파이프라인을 트리거하여 다른 프로젝트에서 하류 파이프라인을 시작할 수 있는데, 이를 다중 프로젝트 파이프라인이라고 합니다. 상류 파이프라인을 트리거하는 사용자는 하류 프로젝트에서 파이프라인을 시작할 수 있어야 하며, 그렇지 않으면 하류 파이프라인은 시작하지 못합니다.
다중 프로젝트 파이프라인:
- 다른 프로젝트의 파이프라인에서 트리거되지만, 상류(트리거) 파이프라인은 하류(트리거된) 파이프라인에 대해 많은 제어 권한이 없습니다. 그러나 하류 파이프라인의 참조를 선택하고 CI/CD 변수를 전달할 수 있습니다.
- 해당 프로젝트의 참조의 전체 상태에 영향을 미치지만, 트리거한 파이프라인의 참조 상태에는 영향을 주지 않습니다. 단,
strategy:depend
로 트리거된 경우에만 해당합니다. - 상류 파이프라인의 하위 프로젝트에서 새로운 참조에 대해 새로운 파이프라인이 실행될 때 자동으로 취소되지 않습니다. 하류 프로젝트에서 동일한 참조에 대해 새로운 파이프라인이 트리거되면 자동으로 취소될 수 있습니다.
- 하류 프로젝트의 파이프라인 목록에 표시됩니다.
- 독립적으로 실행되므로 중첩 제한이 없습니다.
공개 프로젝트를 사용하여 비공개 프로젝트에서 하류 파이프라인을 트리거하는 경우, 기밀성 문제가 없는지 확인하세요. 상류 프로젝트의 파이프라인 페이지에서는 항상 다음이 표시됩니다:
- 하류 프로젝트의 이름.
- 파이프라인의 상태.
.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
트리거 작업이 시작되면 GitLab은 하류 파이프라인을 만들기 위해 시도하는 동안 작업의 초기 상태가 대기중
입니다. 하류 파이프라인이 성공적으로 생성되면 트리거 작업은 성공
으로 표시됩니다. 그렇지 않으면 실패
로 표시됩니다. 또는 트리거 작업을 하류 파이프라인의 상태로 설정할 수 있습니다.
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 "이 작업은 다중 프로젝트와 머지 리퀘스트 파이프라인에서 실행됩니다"
다른 프로젝트의 자식 파이프라인 구성 파일 사용
- GitLab 13.5에서 도입됨.
트리거 작업에서 include:project
를 사용하여 다른 프로젝트의 구성 파일로 자식 파이프라인을 트리거할 수 있습니다:
microservice_a:
trigger:
include:
- project: 'my-group/my-pipeline-library'
ref: 'main'
file: '/path/to/child-pipeline.yml'
여러 자식 파이프라인 구성 파일 결합
자식 파이프라인을 정의할 때 최대 3개의 구성 파일을 포함할 수 있습니다. 자식 파이프라인의 구성은 모든 구성 파일이 병합된 것으로 구성됩니다:
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와 같은 기타 템플릿 언어에 대해서도 비슷한 프로세스를 사용할 수 있습니다.
동적 자식 파이프라인 트리거
동적으로 생성된 구성 파일에서 자식 파이프라인을 트리거하려면:
-
작업에서 구성 파일을 생성하고 아티팩트로 저장합니다:
generate-config: stage: build script: generate-ci-config > generated-config.yml artifacts: paths: - generated-config.yml
-
트리거된 작업에서 아티팩트를 가져오고, 생성된 아티팩트를
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 구성은 \
를 사용합니다.
병합 요청 파이프라인에서 자식 파이프라인 실행
자식 파이프라인을 포함하여 파이프라인은 기본적으로 병합 요청 (부모) 파이프라인에서 트리거될 때 rules
또는 workflow:rules
를 사용하지 않을 경우 브랜치 파이프라인으로 실행됩니다.
병합 요청 파이프라인에서 트리거된 경우 자식 파이프라인을 실행하려면 rules
또는 workflow:rules
를 사용하세요.
예를 들어, rules
를 사용하는 경우:
-
부모 파이프라인의 트리거 작업을 병합 요청에서 실행하도록 설정합니다:
trigger-child-pipeline-job: trigger: include: path/to/child-pipeline-configuration.yml rules: - if: $CI_PIPELINE_SOURCE == "merge_request_event"
-
부모 파이프라인에서 트리거된 자식 파이프라인 작업을 구성하는 데
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 13.2에서 도입되었습니다.
파이프라인 그래프 보기에서 하류 파이프라인은 그래프 오른쪽에 있는 카드 목록으로 표시됩니다. 이 보기에서 다음을 할 수 있습니다:
- 트리거 작업을 선택하여 트리거된 하류 파이프라인의 작업을 볼 수 있습니다.
- 파이프라인 카드에서 작업 확장 을 선택하여 하류 파이프라인의 작업을 확장하여 볼 수 있습니다. 한 번에 하나의 하류 파이프라인만 볼 수 있습니다.
- 파이프라인 카드 위로 마우스를 가져가면 하류 파이프라인을 트리거한 작업이 강조 표시됩니다.
하위 파이프라인에서 실패한 작업을 다시 시도하고 취소하기
- 실패한 작업을 그래프 뷰에서 다시 시도하는 기능은 GitLab 15.0에서 입히고 기본적으로 꺼진 상태인
downstream_retry_action
라는 이름의 기능 플래그와 함께 등장합니다.- 실패한 작업을 그래프 뷰에서 다시 시도하는 기능은 GitLab 15.1에서 일반적으로 이용 가능하며 기능 플래그가 제거되었습니다.
실패한 작업 및 취소된 작업을 다시 시도하려면 다시 시도를 선택하십시오():
- 하류 파이프라인의 세부 페이지에서.
- 파이프라인 그래프 보기의 파이프라인 카드에서.
하류 파이프라인 다시 생성하기
- 실패한 작업을 그래프 뷰에서 다시 시도하는 기능은 GitLab 15.10에서 입히고 기본적으로 꺼진 상태인
ci_recreate_downstream_pipeline
라는 이름의 기능 플래그와 함께 등장합니다.- GitLab 15.11에서 일반적으로 이용 가능하며 기능 플래그가 제거되었습니다.
ci_recreate_downstream_pipeline
라는 기능 플래그가 제거되었습니다.
다시 시도하면 새로 생성된 하류 파이프라인이 파이프라인 그래프에서 현재의 하류 파이프라인을 대신합니다.
하류 파이프라인을 다시 생성하려면 다음을 수행합니다:
- 파이프라인 그래프 보기의 트리거 작업 카드에서 다시 실행을 선택하십시오().
하류 파이프라인 취소하기
- 실패한 작업을 그래프 뷰에서 다시 시도하는 기능은 GitLab 15.0에서 입히고 기본적으로 꺼진 상태인
downstream_retry_action
라는 이름의 기능 플래그와 함께 등장합니다.- 실패한 작업을 그래프 뷰에서 다시 시도하는 기능은 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
이 예제에서:
- 부모 파이프라인은 자식 파이프라인과
job3
을 동시에 트리거합니다. - 자식 파이프라인의
job2
가 실패하면 자식 파이프라인이 취소되어job1
도 중단됩니다. - 자식 파이프라인이 취소되었으므로 부모 파이프라인이 자동으로 취소됩니다.
하향스트림 파이프라인의 상태를 트리거 작업에서 미러링하기
strategy: depend
를 사용하여 하향스트림 파이프라인의 상태를 트리거 작업에서 미러링할 수 있습니다.
trigger_job:
trigger:
include:
- local: path/to/child-pipeline.yml
strategy: depend
trigger_job:
trigger:
project: my/project
strategy: depend
파이프라인 그래프에서 다중 프로젝트 파이프라인 보기
- [16.8에서 GitLab Premium에서 GitLab Free로 이동]((https://gitlab.com/gitlab-org/gitlab/-/issues/422282).
다중 프로젝트 파이프라인을 트리거한 후, 하향스트림 파이프라인은 파이프라인 그래프 오른쪽에 표시됩니다.
파이프라인 미니 그래프에서는 하향스트림 파이프라인이 미니 그래프 오른쪽에 표시됩니다.
상위스트림 파이프라인에서 아티팩트 가져오기
upstream pipeline에서 아티팩트 가져오기에 needs:pipeline:job
를 사용합니다:
-
상위스트림 파이프라인에서
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
-
하향스트림 파이프라인의 작업에서
needs:pipeline:job
를 사용하여 아티팩트를 가져옵니다.test: stage: test script: - cat artifact.txt needs: - pipeline: $PARENT_PIPELINE_ID job: build_artifacts
job
를 아티팩트를 생성한 상위스트림 파이프라인의 작업으로 설정하세요.
upstream pipeline에서 아티팩트 가져오기에 needs:project
를 사용합니다:
- GitLab 15.9 이상에서, 상위 프로젝트의 작업 토큰 범위 허용 목록에 하향 프로젝트 추가합니다.
-
상위스트림 파이프라인에서
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 # 하향 파이프라인 트리거할 프로젝트 경로
-
하향스트림 파이프라인의 작업에서
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입니다. 협의 요청 파이프라인의 경우에는 브랜치 이름을 ref
로 사용하지 마십시오. 왜냐하면 하향 파이프라인이 최신 브랜치 파이프라인에서 아티팩트를 가져오려고 하기 때문입니다.
CI_MERGE_REQUEST_REF_PATH
CI/CD 변수를 사용하여 상위 협의 요청
파이프라인에서 아티팩트를 가져오는 대신에 CI_MERGE_REQUEST_REF_PATH
를 변수 상속을 사용하여 하향 파이프라인으로 전달할 수 있습니다:
- GitLab 15.9 이상에서, 상위 프로젝트의 작업 토큰 범위 허용 목록에 하향 프로젝트 추가합니다.
- 상위스트림 파이프라인의 작업에서
artifacts
키워드를 사용하여 아티팩트를 저장합니다. -
하향 파이프라인을 트리거하는 작업에서
$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
-
하향 파이프라인의 작업에서
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 변수를 다운스트림 파이프라인으로 전달할 수 있습니다. 이는 변수가 생성되거나 정의된 위치에 따라 다릅니다.
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
를 상속받기 때문입니다.
전역 변수의 전달 방지
inherit:variables:false
를 사용하여 전역 CI/CD 변수가 다운스트림 파이프라인에 전달되는 것을 막을 수 있습니다.
예를 들어:
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 변수를 사용하여 상위 파이프라인에 대한 정보를 전달하려면 보간법(interpolation)을 사용합니다. 미리 정의된 변수를 새 작업 변수로 저장하고, 해당 변수를 다운스트림 파이프라인으로 전달하는 트리거 작업을 생성합니다. 예를 들어:
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
값이 포함된 UPSTREAM_BRANCH
변수를 사용할 수 있습니다.
이 방법을 사용하여 마스킹된 변수를 다중 프로젝트 파이프라인으로 전달하지 마십시오. CI/CD 마스킹 구성이 다운스트림 파이프라인으로 전달되지 않고, 변수가 다운스트림 프로젝트의 작업 로그에서 unmasked될 수 있습니다.
이 방법을 사용하여 작업 수준의 지속 변수를 다운스트림 파이프라인으로 전달할 수는 없습니다. 이러한 변수는 트리거 작업에서 사용할 수 없기 때문입니다.
상위 파이프라인이 우선합니다. 상위 및 하위 프로젝트에서 동일한 이름으로 정의된 두 변수가 있는 경우, 상위 프로젝트에서 정의된 변수가 우선합니다.
작업에서 생성된 dotenv 변수를 전달
세부 정보: Tier: Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated
dotenv
변수 상속을 사용하여 변수를 다운스트림 파이프라인으로 전달할 수 있습니다.
예를 들어, 다중 프로젝트 파이프라인에서:
-
.env
파일에 변수를 저장합니다. -
.env
파일을dotenv
보고서로 저장합니다. -
다운스트림 파이프라인을 트리거합니다.
build_vars: stage: build script: - echo "BUILD_VERSION=hello" >> build.env artifacts: reports: dotenv: build.env deploy: stage: deploy trigger: my/downstream_project
-
다운스트림 파이프라인의
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
키워드를 사용하여 다운스트림 파이프라인으로 전달할 변수 유형을 지정합니다. 전달된 변수는 트리거 변수로 간주되며, 가장 높은 우선순위를 갖습니다.
배포를 위한 다운스트림 파이프라인
- GitLab 16.4에서 도입되었습니다.
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 "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"
문제 해결
트리거 작업이 실패하고 다중 프로젝트 파이프라인이 생성되지 않음
다중 프로젝트 파이프라인에서 트리거 작업이 실패하고 다운스트림 파이프라인이 생성되지 않는 경우:
- 다운스트림 프로젝트를 찾을 수 없는 경우.
- 상위 파이프라인을 생성하는 사용자에게 다운스트림 프로젝트에서 파이프라인을 생성할 수 있는 권한이 없는 경우.
- 다운스트림 파이프라인이 보호된 브랜치를 대상으로 하고 사용자가 보호된 브랜치에 대한 파이프라인 실행 권한이 없는 경우. 자세한 내용은 보호된 브랜치에 대한 파이프라인 보안을 참조하십시오.
다운스트림 프로젝트에서 권한 문제를 겪고 있는 사용자를 확인하려면 다음 명령을 Rails 콘솔에서 사용하여 트리거 작업을 확인하고 user_id
속성을 살펴보세요.
Ci::Bridge.find(<job_id>)
부모 파이프라인이 실행되지 않을 때 하위 파이프라인 작업이 생성되지 않음
부모 파이프라인이 병합 요청 파이프라인인 경우, 하위 파이프라인은 작업이 실행되도록 workflow:rules
또는 rules
를 사용해야 합니다.
하위 파이프라인의 작업이 누락될 수 있거나 올바르지 않은 rules
구성으로 인해 실행되지 않는 경우:
- 하위 파이프라인이 시작되지 않습니다.
- 부모 파이프라인의 트리거 작업이 다음과 같은 오류와 함께 실패합니다:
다운스트림 파이프라인을 생성할 수 없습니다. 규칙 구성으로 인해 파이프라인에 작업을 추가할 수 없습니다.
Ref is ambiguous
동일한 이름의 태그가 있는 브랜치가 존재하는 경우 태그로 다중 프로젝트 파이프라인을 트리거할 수 없습니다. 다음 오류와 함께 다운스트림 파이프라인 생성에 실패합니다: 다운스트림 파이프라인을 생성할 수 없습니다. 참조가 모호합니다.
태그 이름이 브랜치 이름과 일치하지 않는 경우에만 다중 프로젝트 파이프라인을 트리거하세요.
상위 파이프라인에서 작업 아티팩트 다운로드 시 403 Forbidden
오류
GitLab 15.9 이상에서 CI/CD 작업 토큰은 파이프라인이 실행되는 프로젝트에 대해 범위가 지정됩니다. 따라서 다운스트림 파이프라인의 작업 토큰을 사용하여 기본적으로 상위 프로젝트에 접근할 수 없습니다.
이를 해결하려면 다운스트림 프로젝트를 작업 토큰 범위 허용 목록에 추가하세요.