- 부모-자식 파이프라인
- 다중 프로젝트 파이프라인
-
.gitlab-ci.yml파일에서 작업을 통해 하류 파이프라인을 트리거 - API를 사용하여 다중 프로젝트 파이프라인 트리거
- 다운스트림 파이프라인 보기
- 상위 파이프라인에서 아티팩트 가져오기
- CI/CD 변수를 하류 파이프라인으로 전달
- 배포를 위한 하위 파이프라인
하류 파이프라인
하류 파이프라인은 다른 파이프라인에 의해 트리거되는 모든 GitLab CI/CD 파이프라인을 의미합니다. 하류 파이프라인은 트리거한 상류 파이프라인과 독립적으로 동시에 실행됩니다.
- 부모-자식 파이프라인은 첫 번째 파이프라인과 같은 프로젝트에서 트리거되는 하류 파이프라인입니다.
- 다중 프로젝트 파이프라인은 첫 번째 파이프라인이 다른 프로젝트에서 트리거되는 하류 파이프라인입니다.
가끔 부모-자식 파이프라인 및 다중 프로젝트 파이프라인을 유사한 목적으로 사용할 수 있지만, 중요한 차이점이 있습니다.
부모-자식 파이프라인
부모 파이프라인은 동일한 프로젝트에서 하류 파이프라인을 트리거하는 파이프라인입니다. 하류 파이프라인을 자식 파이프라인이라고 합니다.
자식 파이프라인:
- 부모 파이프라인과 동일한 프로젝트, 참조, 및 커밋 SHA에서 실행됩니다.
-
파이프라인이 실행 중인 참조의 전반적인 상태에 직접적인 영향을 주지 않습니다. 예를 들어, 주 브랜치에서 파이프라인이 실패하면 “주 브랜치가 깨졌다”라고 말하는 것이 일반적입니다. 자식 파이프라인의 상태는 자식 파이프라인이
strategy:depend로 트리거된 경우에만 참조의 상태에 영향을 줍니다. - 동일한 참조에 대해 새 파이프라인이 생성될 때 자동으로 취소됩니다.
즉
interruptible로 구성된 파이프라인에서 생성된 새 파이프라인에 대해 자동으로 취소됩니다. - 프로젝트의 파이프라인 목록에 표시되지 않습니다. 자식 파이프라인은 부모 파이프라인의 세부 정보 페이지에서만 볼 수 있습니다.
중첩된 자식 파이프라인
부모 및 자식 파이프라인에는 두 수준의 자식 파이프라인이 최대 제한입니다.
부모 파이프라인은 많은 자식 파이프라인을 트리거할 수 있으며, 이러한 자식 파이프라인은 자체 자식 파이프라인을 트리거할 수 있습니다. 그러나 또 다른 수준의 자식 파이프라인을 트리거할 수는 없습니다.
개요는 중첩 동적 파이프라인을 참조하세요.
다중 프로젝트 파이프라인
한 프로젝트의 파이프라인은 다른 프로젝트에서 하류 파이프라인을 트리거할 수 있으며, 이를 다중 프로젝트 파이프라인이라고 합니다. 상류 파이프라인을 트리거하는 사용자는 다운스트림 프로젝트에서 파이프라인을 시작할 수 있어야 합니다. 그렇지 않으면 하류 파이프라인이 시작하지 못합니다.
다중 프로젝트 파이프라인:
- 다른 프로젝트의 파이프라인에서 트리거되지만, 상류(트리거) 파이프라인은 하류(트리거된) 파이프라인에 대해 많은 제어를 할 수 없습니다. 그러나 하류 파이프라인의 참조를 선택하고 CI/CD 변수를 하류 파이프라인에 전달할 수 있습니다.
- 프로젝트의 참조 전반적인 상태에 영향을 줍니다. 그러나 상류 파이프라인의 참조 상태에는
영향을 주지 않습니다 unless it was triggered with
strategy:depend. - 상류 파이프라인에서 동일한 참조에 대해 새 파이프라인이 실행된 경우,
interruptible를 사용하는 경우 자동으로 취소되지 않습니다. 그러나 하류 프로젝트에서 동일한 참조에 대한 새 파이프라인이 트리거된 경우 자동으로 취소될 수 있습니다. - 하류 프로젝트의 파이프라인 목록에 표시됩니다.
- 독립적이므로 중첩 제한이 없습니다.
공개 프로젝트를 사용하여 비공개 프로젝트에서 하류 파이프라인을 트리거하는 경우, 기밀성 문제가 없는지 확인하세요. 상류 프로젝트의 파이프라인 페이지에는 항상 다음이 표시됩니다:
- 하류 프로젝트의 이름.
- 파이프라인의 상태.
.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
트리거 작업을 시작하면, 작업의 초기 상태는 하류 파이프라인을 생성하려고 할 때 대기 중으로 표시됩니다.
하류 파이프라인이 성공적으로 생성되면 트리거 작업은 통과됨으로 표시되고, 그렇지 않은 경우 실패함으로 표시됩니다.
또는 트리거 작업에서 하류 파이프라인의 상태를 설정할 수 있습니다.
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보다 크면 안 됩니다.
개요를 보려면 동적으로 생성된 구성을 사용하여 자식 파이프라인 만들기를 참조하십시오.
동적 자식 파이프라인을 생성하는 예제 프로젝트는 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 러너를 사용하는 경우 트리거 작업의 경로 구분 기호는 /입니다. 스크립트와 같은 윈도우 러너를 사용하는 작업에 대한 다른 CI/CD 구성은 \을 사용합니다.
동적 자식 파이프라인 구성의 include 섹션에 CI/CD 변수를 사용할 수 없습니다.
Issue 378717에서 이 문제를 수정하는 것이 제안되었습니다.
머지 리퀘스트 파이프라인과 함께 자식 파이프라인 실행
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_MERGE_REQUEST_ID를 대신 사용하여 상위 파이프라인이 머지 리퀘스트 파이프라인일 때만 자식 파이프라인 작업을 설정합니다. 상위 파이프라인의CI_MERGE_REQUEST_*predefined variables가 자식 파이프라인 작업으로 전달됩니다.
다중 프로젝트 파이프라인에 대한 브랜치 지정
다중 프로젝트 파이프라인을 트리거할 때 사용할 브랜치를 지정할 수 있습니다. GitLab은 브랜치의 헤드에 있는 커밋을 사용하여 다운스트림 파이프라인을 생성합니다. 예를 들어:
staging:
stage: deploy
trigger:
project: my/deployment
branch: stable-11-2
사용할 수 있습니다:
-
project키워드를 사용하여 다운스트림 프로젝트의 전체 경로를 지정합니다. GitLab 15.3 이상에서는 변수 확장을 사용할 수 있습니다. -
branch키워드를 사용하여project에서 지정된 프로젝트의 브랜치나 태그의 이름을 지정합니다. 변수 확장을 사용할 수 있습니다.
API를 사용하여 다중 프로젝트 파이프라인 트리거
CI/CD job token (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에서 소개된 그래프 뷰에서 다시 시도 기능, 기본 설정으로는 비활성화된
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
파이프라인 그래프에서 다중 프로젝트 파이프라인 보기
다중 프로젝트 파이프라인을 트리거하면 하향 파이프라인이 파이프라인 그래프 오른쪽에 표시됩니다.
파이프라인 미니 그래프에서 하향 파이프라인은 미니 그래프 오른쪽에 표시됩니다.
상위 파이프라인에서 아티팩트 가져오기
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을 설정하세요.
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 변수를 사용하여 검색할 수 있습니다. 병합 요청 파이프라인에서 ref로 브랜치명을 사용하지 마십시오. 왜냐하면 하류 파이프라인이 최신 브랜치 파이프라인에서 생성물을 검색하려고 시도하기 때문입니다.
브랜치 파이프라인이 아닌 상류 병합 요청 파이프라인에서 생성물을 검색하려면 변수 상속을 사용하여 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
UPSTREAM_BRANCH 변수는 하류 파이프라인에서 사용할 수 있으며, 이 변수에는 상류 파이프라인의 $CI_COMMIT_REF_NAME 사전 정의 CI/CD 변수 값이 포함됩니다.
마스크된 변수를 다중 프로젝트 파이프라인으로 전달하는 데 이 방법을 사용하지 마십시오. CI/CD 마스킹 구성은 하류 파이프라인으로 전달되지 않으며, 하류 프로젝트의 작업 로그에서 변수가 노출될 수 있습니다.
또한, 작업 전용 변수를 하류 파이프라인으로 전달하는 데 이 방법을 사용할 수 없습니다. 왜냐하면 이러한 변수는 트리거 작업에서 사용할 수 없기 때문입니다.
상류 파이프라인은 하류 파이프라인보다 우선합니다. 상류 및 하류 프로젝트에서 동일한 이름을 가진 두 변수가 정의되어 있는 경우 상류 프로젝트에서 정의된 변수가 우선적으로 사용됩니다.
작업에서 생성된 dotenv 변수 전달
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 키워드를 사용합니다. 전달된 변수는 트리거 변수로 간주되며, 이것은 가장 높은 우선순위를 가지게 됩니다.
배포를 위한 하위 파이프라인
trigger 키워드와 함께 environment 키워드를 사용할 수 있습니다.
배포 및 애플리케이션 프로젝트를 별도로 관리하는 경우 트리거 작업에서 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"
도움말