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

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ジョブがテスト段階で成功するとすぐにstagingbridgeジョブが開始されます。このジョブの初期状態はpendingです。GitLabはmy/deploymentプロジェクトに下流のパイプラインを作成し、パイプラインが作成されるとすぐにstagingジョブが成功します。my/deploymentは、そのプロジェクトへのフルパスです。

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

Caution: この例では、下流のパイプラインが作成されるとすぐにstagingが成功したと表示されます。代わりに下流のパイプラインのステータスを表示したい場合は、「起動されたパイプラインからのミラーリング状況」を参照してください。
Note: ブリッジジョブは、ユーザーが通常のジョブで使用できるすべての設定項目をサポートしていません。ブリッジジョブはランナーによって選択されないため、例えば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がジョブを選択する際に、環境変数として利用できます。

以下の設定では、trigger-downstreamジョブがキューイングされた際に作成される下流のパイプラインにMY_VARIABLE変数が渡されます。これは、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ジョブに渡され、すべての下流のビルドのコンテキスト内で利用できるようになります。

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

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

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 and except
  • when(on_success、on_failure、alwaysの各値のみ)
  • extends

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

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

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

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

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