ダウンストリームパイプライン

プラン: Free、Premium、Ultimate
提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

ダウンストリームパイプラインとは、別のパイプラインによってトリガーされるGitLab CI/CDパイプラインのことです。ダウンストリームパイプラインは、トリガーしたアップストリームパイプラインとは独立して同時に実行されます。

親子パイプラインは、最初のパイプラインと同じプロジェクトでトリガーされるダウンストリームパイプラインです。
マルチプロジェクトパイプラインは、最初のパイプラインとは異なるプロジェクトでトリガーされるダウンストリームパイプラインです。

親子パイプラインとマルチプロジェクトパイプラインは同様の目的で使用できる場合がありますが、重要な違いがあります。

パイプライン階層には、デフォルトで最大1000個のダウンストリームパイプラインを含めることができます。この制限とその変更方法について詳しくは、パイプライン階層サイズを制限するを参照してください。

親子パイプライン

親パイプラインとは、同じプロジェクト内のダウンストリームパイプラインをトリガーするパイプラインのことです。ダウンストリームパイプラインは、子パイプラインと呼ばれます。

子パイプライン:

親パイプラインと同じプロジェクト、ref、コミットSHAで実行されます。
パイプライン実行の対象となるrefの全体的なステータスには直接影響しません。たとえば、mainブランチのパイプラインが失敗した場合、一般的には「mainが壊れている」と言われます。子パイプラインのステータスは、trigger:strategyで子パイプラインがトリガーされた場合にのみ、refのステータスに影響します。
同じrefに対して新しいパイプラインが作成されるとき、パイプラインがinterruptibleで設定されている場合、自動的にキャンセルされます。
プロジェクトのパイプラインリストには表示されません。子パイプラインは、親パイプラインの詳細ページでのみ表示できます。

ネストされた子パイプライン

親パイプラインと子パイプラインは、最大で2階層までの子パイプラインを持つことができます。

親パイプラインは多数の子パイプラインをトリガーでき、これらの子パイプラインも自身の子パイプラインをトリガーできます。そのさらに下の階層の子パイプラインをトリガーすることはできません。

概要については、Nested Dynamic Pipelines（ネストされた動的パイプライン）をご覧ください。

マルチプロジェクトパイプライン

あるプロジェクトのパイプラインが別のプロジェクトのダウンストリームパイプラインをトリガーできます。これはマルチプロジェクトパイプラインと呼ばれます。アップストリームパイプラインをトリガーするユーザーには、ダウンストリームプロジェクトでパイプラインを開始できる権限が必要です。そうでない場合、ダウンストリームパイプラインの開始に失敗します。

マルチプロジェクトパイプライン:

別のプロジェクトのパイプラインからトリガーされますが、アップストリーム（トリガーする）パイプラインはダウンストリーム（トリガーされる）パイプラインをあまり制御できません。ただし、ダウンストリームパイプラインのrefを選択したり、CI/CD変数を渡したりすることはできます。
ダウンストリームパイプラインが実行されるプロジェクトのrefの全体的なステータスには影響しますが、trigger:strategyでトリガーされない限り、トリガー元のパイプラインのrefのステータスには影響しません。
アップストリームパイプラインで同じ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

トリガージョブが開始されると、GitLabがダウンストリームパイプラインの作成を試行している間、ジョブの初期ステータスはpendingになります。ダウンストリームパイプラインが正常に作成された場合、トリガージョブはpassedを表示し、それ以外の場合はfailedを表示します。または、代わりにダウンストリームパイプラインのステータスを表示するようにトリガージョブを設定することもできます。

`rules`を使用してダウンストリームパイプラインのジョブを制御する

CI/CD変数またはrulesキーワードを使用して、ダウンストリームパイプラインのジョブの動作を制御します。

triggerキーワードでダウンストリームパイプラインをトリガーすると、すべてのジョブにおける$CI_PIPELINE_SOURCE定義済み変数の値は次のようになります:

マルチプロジェクトパイプラインの場合: pipeline。
親子パイプラインの場合: parent_pipeline。

たとえば、マージリクエストパイプラインも実行するプロジェクトでマルチプロジェクトパイプラインのジョブを制御するには、次のようになります:

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"

別のプロジェクトで子パイプライン設定ファイルを使用する

トリガージョブで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ファイルを含むアーティファクトは、インスタンスの制限内に存在する必要があります。

概要については、Create child pipelines using dynamically generated configurations（動的に生成された設定を使用して子パイプラインを作成する）をご覧ください。

動的な子パイプラインを生成するプロジェクトの例については、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設定で子パイプラインをトリガーします。

アーティファクトのパスはRunnerではなくGitLabによって解析されるため、パスはGitLabを実行しているOSの構文に一致している必要があります。GitLabがLinuxで実行されていても、テストにWindows Runnerを使用している場合、トリガージョブのパス区切り文字は/になります。スクリプトなど、Windows Runnerを使用するジョブの他のCI/CD設定では、\を使用します。

動的な子パイプラインの設定のincludeセクションでは、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 "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"を使用して、子パイプラインのジョブを常に実行させることができます。
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を使用してマルチプロジェクトパイプラインをトリガーする

パイプライントリガーAPIエンドポイントでCI/CDジョブトークン（CI_JOB_TOKEN）を使用して、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

ダウンストリームパイプラインを表示する

パイプラインの詳細ページでは、ダウンストリームパイプラインは、グラフの右側にカードのリストとして表示されます。このビューでは、次のことができます:

トリガージョブを選択して、トリガーされたダウンストリームパイプラインのジョブを表示する。
パイプラインカードでジョブを展開 を選択し、そのダウンストリームパイプラインのジョブを展開して表示する。同時に表示できるのは1つのダウンストリームパイプラインのみです。
パイプラインカードの上にカーソルを合わせ、ダウンストリームパイプラインをトリガーしたジョブを強調表示する。

ダウンストリームパイプラインで失敗およびキャンセルされたジョブを再試行する

失敗およびキャンセルされたジョブを再試行するには、次の場所で再試行（）を選択します:

ダウンストリームパイプラインの詳細ページ。
パイプライングラフビューのパイプラインカード上。

ダウンストリームパイプラインを再作成する

対応するトリガージョブを再試行することで、ダウンストリームパイプラインを再作成できます。新しく作成されたダウンストリームパイプラインは、パイプライングラフ内の現在のダウンストリームパイプラインを置き換えます。

次の方法で、ダウンストリームパイプラインを再作成できます:

パイプライングラフビューでトリガージョブのカードの再実行（）を選択する。

ダウンストリームパイプラインをキャンセルする

まだ実行中のダウンストリームパイプラインをキャンセルするには、次の場所でキャンセル（）を選択します:

ダウンストリームパイプラインの詳細ページ。
パイプライングラフビューのパイプラインカード上。

ダウンストリームパイプラインから親パイプラインを自動キャンセルする

いずれかのジョブが失敗した時点で自動キャンセルされるように子パイプラインを設定できます。

子パイプラインのジョブが失敗したときに親パイプラインが自動キャンセルされるのは、次の場合のみです:

親パイプラインもジョブの失敗時に自動キャンセルするように設定されている。
トリガージョブが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

この例では、次のようになります:

親パイプラインは子パイプラインとjob3を同時にトリガーします。
子パイプラインからのjob2が失敗し、子パイプラインがキャンセルされ、job1も停止します。
子パイプラインがキャンセルされたため、親パイプラインは自動キャンセルされます。

トリガージョブでダウンストリームパイプラインのステータスをミラーリングする

strategy: mirrorを使用して、トリガージョブでダウンストリームパイプラインのステータスをミラーリングできます:

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

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

パイプライングラフでマルチプロジェクトパイプラインを表示する

マルチプロジェクトパイプラインをトリガーすると、ダウンストリームパイプラインがパイプライングラフの右側に表示されます。

パイプラインミニグラフでは、ダウンストリームパイプラインはミニグラフの右側に表示されます。

子パイプラインのレポートをマージリクエストで表示する

マージリクエストウィジェットで子パイプラインからのレポートを表示できます。これにより、複数のパイプラインを手動でナビゲートして障害を特定しなくても、パイプライン階層全体のテスト結果と品質チェックの統一されたビューが提供されます。

次のレポートタイプが子パイプラインからサポートされています:

単体テストレポート（Junit）
Code Qualityレポート
Terraformレポート
メトリクスレポート

子パイプラインからのテスト結果は、親パイプラインのテストタブにも表示されます。

マージリクエストウィジェットで完全なレポート情報を確認するには、アーティファクトレポートを生成する子パイプラインで、strategy: dependまたはstrategy: mirrorを使用する必要があります。

次に例を示します:

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

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

アップストリームパイプラインからアーティファクトをフェッチする

プラン: Premium、Ultimate
提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

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以降では、アップストリームプロジェクトのジョブトークンスコープの許可リストにダウンストリームプロジェクトを追加します。

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

ダウンストリームパイプラインのジョブで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としてブランチ名を使用しないでください。そうすると、ダウンストリームパイプラインが最新のブランチパイプラインからアーティファクトをフェッチしようとしてしまいます。

branchパイプラインではなく、アップストリームのmerge requestパイプラインからアーティファクトをフェッチするには、変数の継承を使用して、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
```

この方法を使用してアップストリームマージリクエストパイプラインからアーティファクトをフェッチできますが、マージ結果パイプラインからはフェッチできません。

ダウンストリームパイプラインに入力を渡す

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変数は、ダウンストリームパイプラインで定義されたすべてのジョブで使用できます。

VERSIONデフォルト変数も、ダウンストリームパイプラインで使用できます。これは、トリガージョブを含むパイプライン内のすべてのジョブがデフォルト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変数を使用してアップストリームパイプラインに関する情報を渡すには、補間を使用します。定義済み変数をトリガージョブの新しいジョブ変数として保存し、ダウンストリームパイプラインに渡します。次に例を示します:

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のマスキング設定はダウンストリームパイプラインに渡されないため、ダウンストリームプロジェクトのジョブログで変数がマスク解除されるおそれがあります。

この手法を使用してジョブ専用変数をダウンストリームパイプラインに渡すことはできません。トリガージョブではそれらの変数を使用できないためです。

アップストリームパイプラインは、ダウンストリームパイプラインよりも優先されます。アップストリームプロジェクトとダウンストリームプロジェクトの両方で同じ名前の2つの変数が定義されている場合、アップストリームプロジェクトで定義されている変数が優先されます。

ジョブで作成されたdotenv変数を渡す

プラン: Premium、Ultimate
提供形態: GitLab.com、GitLab 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キーワードを使用して、ダウンストリームパイプラインに転送する変数のタイプを指定します。転送された変数はトリガー変数と見なされ、優先順位が最も高くなります。

デプロイのダウンストリームパイプライン

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: 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"

ダウンストリームパイプライン

親子パイプライン

ネストされた子パイプライン

マルチプロジェクトパイプライン

.gitlab-ci.ymlファイル内のジョブからダウンストリームパイプラインをトリガーする

rulesを使用してダウンストリームパイプラインのジョブを制御する

別のプロジェクトで子パイプライン設定ファイルを使用する

複数の子パイプライン設定ファイルを結合する

動的な子パイプライン

動的な子パイプラインをトリガーする

マージリクエストパイプラインで子パイプラインを実行する

マルチプロジェクトパイプラインのブランチを指定する

APIを使用してマルチプロジェクトパイプラインをトリガーする

ダウンストリームパイプラインを表示する

ダウンストリームパイプラインで失敗およびキャンセルされたジョブを再試行する

ダウンストリームパイプラインを再作成する

ダウンストリームパイプラインをキャンセルする

ダウンストリームパイプラインから親パイプラインを自動キャンセルする

トリガージョブでダウンストリームパイプラインのステータスをミラーリングする

パイプライングラフでマルチプロジェクトパイプラインを表示する

子パイプラインのレポートをマージリクエストで表示する

アップストリームパイプラインからアーティファクトをフェッチする

アップストリームマージリクエストパイプラインからアーティファクトをフェッチする

ダウンストリームパイプラインに入力を渡す

CI/CD変数をダウンストリームパイプラインに渡す

YAMLで定義されたCI/CD変数を渡す

デフォルト変数が渡されないようにする

定義済み変数を渡す

ジョブで作成されたdotenv変数を渡す

ダウンストリームパイプラインに転送する変数のタイプを制御する

デプロイのダウンストリームパイプライン

高度な例

`.gitlab-ci.yml`ファイル内のジョブからダウンストリームパイプラインをトリガーする

`rules`を使用してダウンストリームパイプラインのジョブを制御する