複数プロジェクトのパイプライン

GitLab CI/CDを複数のプロジェクトにまたがって設定でき、あるプロジェクトのパイプラインが別のプロジェクトのパイプラインを起動できます。

GitLab CI/CDは、プロジェクト単位だけでなく、複数プロジェクトパイプラインによるプロジェクト間の連携も可能な強力な継続的インテグレーションツールです。

複数プロジェクトパイプラインは、マイクロサービスアーキテクチャを採用しているような、プロジェクト間の相互依存を必要とする大規模な製品に有効です。

クロスファンクショナルな開発チームがクロスパイプライントリガーを使用して、異なるマイクロサービスプロジェクトの複数のパイプラインを起動するデモを用意しました。「Cross-project Pipeline Triggering and Visualization」をご覧ください。

さらに、プロジェクト間の相互依存関係を含むパイプライン全体を可視化することも可能です。

ユースケース

WebアプリをGitLabの異なるプロジェクトからデプロイするとします。

  • 1つは無料版で、アプリをビルドしてテストする独自のパイプラインを持っています。
  • 1つは有料版アドオンのためのもので、ビルドとテストを無視します。
  • 1つはドキュメント用で、SSGを使用したビルド、テスト、デプロイを行います。

複数プロジェクトのパイプラインでは、3つのプロジェクトのすべてのビルドおよびテストステージを含むパイプライン全体を可視化できます。

マルチプロジェクトパイプラインの可視化

GitLab Premium 9.3で導入されました。

プロジェクトにGitLab CI/CDを設定すると、ジョブのステージをパイプライングラフで可視化できます。

Multi-project pipeline graph

マージリクエストウィジェットでは複数プロジェクトのパイプラインのミニグラフが表示され、ホバーリングやタップ(タッチスクリーン端末の場合)すると、拡大したり隣接して表示できます。

Multi-project mini graph

APIにより起動する複数プロジェクトのパイプライン

  • マルチプロジェクトパイプラインのためのCI_JOB_TOKEN の使用はGitLab Premium9.3 で導入されました。
  • マルチプロジェクトパイプラインのためのCI_JOB_TOKEN の使用は、GitLab 12.4 で全ての階層で利用できるようになりました。

CI_JOB_TOKEN を使ってパイプラインをトリガーすると、GitLab はジョブトークンのソースを認識するため、これらのパイプラインを内部で結びつけ、パイプライングラフ上でそれらの関係を可視化することができます。

これらの関係は、上流と下流のパイプラインの依存関係を示すインバウンドとアウトバウンドの接続を示すことで、パイプライングラフに表示されます。

マルチプロジェクトパイプラインの作成.gitlab-ci.yml

ブリッジジョブによるダウンストリームパイプラインの起動

GitLab 11.8以前では、別のプロジェクトのAPIにより起動する複数プロジェクトのパイプラインに担当するパイプラインジョブを実装する必要がありました。

GitLab 11.8では、GitLabは新しいCI/CD設定構文を提供し、このタスクを容易にしてプロジェクト間のパイプラインを起動するためにGitLab Runnerを必要としないようにしています。以下は、ブリッジジョブの設定を説明しています。 

rspec:
  stage: test
  script: bundle exec rspec

staging:
  variables:
    ENVIRONMENT: staging
  stage: deploy
  trigger: my/deployment

上の例では、rspec ジョブがtest ステージで成功するとすぐに、staging ブリッジジョブが開始されます。このジョブの初期ステータスはpendingになります。GitLab はmy/deployment プロジェクトの下流パイプラインを作成し、パイプラインが作成されるとすぐに、staging ジョブが成功します。my/deployment はそのプロジェクトへのフルパスです。

アップストリームパイプラインを作成したユーザーは、ダウンストリームプロジェクト（この場合、my/deployment ）へのアクセス権限を持っている必要があります。ダウンストリームプロジェクトが見つからない場合、またはユーザーがそこにパイプラインを作成するアクセス権限を持っていない場合、staging ジョブは_失敗と_マークされます。

注意:この例では、staging 、ダウンストリームパイプラインが作成されると同時に成功したとマークされます。ダウンストリームパイプラインのステータスを代わりに表示したい場合は、トリガーされたパイプラインからのステータスのミラーリングを参照してください。
注:ブリッジジョブは通常のジョブでユーザーが使用できるすべての設定項目をサポートしません。 ブリッジジョブは Runner によって選択されないので、たとえばscriptのサポートを追加する意味はありません。 ユーザーがサポートされていない設定構文を使用しようとすると、パイプラインの作成時に YAML バリデーションは失敗します。

下流のパイプラインのブランチを指定する

下流のパイプラインが使用するブランチ名を指定可能です。 

rspec:
  stage: test
  script: bundle exec rspec

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

使用方法。

  • project キーワードで、下流プロジェクトのフルパスを指定します。
  • projectで指定したプロジェクト内のブランチ名を指定するbranch キーワード。 GitLab 12.4 から変数展開がサポートされました。

GitLabは、下流のパイプラインを作成する際に、そのブランチの現在のHEADにあるコミットを使用します。

下流のパイプラインへの変数の受け渡し

下流のパイプラインに変数を渡したい場合があります。 その場合は、通常のジョブを定義するときと同じように、variables キーワードを使用します。 

rspec:
  stage: test
  script: bundle exec rspec

staging:
  variables:
    ENVIRONMENT: staging
  stage: deploy
  trigger: my/deployment

ENVIRONMENT 変数は、下流のパイプラインで定義されたすべてのジョブに渡されます。GitLab Runner がジョブを選択するときに、環境変数として利用できるようになります。

以下の設定では、MY_VARIABLE 変数は、trigger-downstream ジョブがキューに入れられた trigger-downstreamときに作成される下流のパイプラインに渡されますtrigger-downstream 。 これは、 trigger-downstreamジョブがグローバル変数ブロックで宣言された変数を継承し、その変数を下流のパイプラインに渡すtrigger-downstream ため trigger-downstreamです。 

variables:
  MY_VARIABLE: my-value

trigger-downstream:
  variables:
    ENVIRONMENT: something
  trigger: my/project

上流のパイプラインに関する情報を、あらかじめ定義された変数などを使って渡したい場合があります。そのためには、補間を使って任意の変数を渡すことができます。たとえば、次のようになります。 

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

このシナリオでは、アップストリームパイプラインに関連する値を持つ変数UPSTREAM_BRANCH がdownstream-job ジョブに渡され、すべてのダウンストリームビルドのコンテキスト内で使用できるようになります。

ヒント:上流パイプラインは下流パイプラインよりも優先されます。 上流プロジェクトと下流プロジェクトの両方で同じ名前の変数が定義されている場合、上流プロジェクトで定義されたものが優先されます。

起動されたパイプラインからのミラーリング状況

strategy: dependを使用して、トリガーされたパイプラインからソースブリッジジョブにパイプラインステータスをミラーリングできます： 

trigger_job:
  trigger:
    project: my/project
    strategy: depend

上流のパイプラインからのミラーリング状況

needs:pipeline キーワードを使用すると、上流パイプラインのパイプラインステータスをブリッジジョブにミラーリングできます。マスタの最新のパイプラインステータスがブリッジジョブに複製されます。

使用例： 

upstream_bridge:
  stage: test
  needs:
    pipeline: other/project

制限事項

ブリッジジョブは通常のジョブとは少し異なるため、ランナーによって選択される通常のジョブを定義するときのように、ここでまったく同じ設定構文を使用できません。

環境への対応など、まだ実装されていない機能もあります。

ブリッジジョブで使用できる設定キーワードは以下のとおりです。

  • trigger (下流のパイプライントリガーを定義するため)
  • stage
  • allow_failure
  • rules
  • only と except
  • when (on_success,on_failure,always の値のみ)
  • extends

上流のプロジェクトが再構築されたときにパイプラインを起動する

GitLab Premium12.8で導入されました。

別のプロジェクトで新しいタグのパイプラインが終了したときに、自分のプロジェクトのパイプラインを起動できます。

  1. プロジェクトの 「設定」＞「CI/CD」ページに移動し、「パイプラインのサブスクリプション」セクションを展開します。
  2. 購読したいプロジェクトのパスを入力します。
  3. 購読するをクリックします。

サブスクライブしたプロジェクトの新しいタグに対して正常に完了したパイプラインは、現在のプロジェクトのデフォルトブランチ上のパイプラインを起動するようになりました。アップストリームパイプラインのサブスクリプションの最大数は、アップストリームプロジェクトとダウンストリームプロジェクトの両方で2です。