- ユースケース
- 複数プロジェクトのパイプライン可視化
- APIにより起動する複数プロジェクトのパイプライン
-
.gitlab-ci.yml
からの複数プロジェクトのパイプラインの作成 - 上流のプロジェクトが再構築されたときにパイプラインを起動する
複数プロジェクトのパイプライン
- GitLab 7.14でビルドトリガーとして導入されました。
- GitLab 12.8では、すべての階層で利用できるようになりました。
GitLab CI/CDを複数のプロジェクトにまたがって設定でき、あるプロジェクトのパイプラインが別のプロジェクトのパイプラインを起動できます。
GitLab CI/CDは、プロジェクト単位だけでなく、複数プロジェクトパイプラインによるプロジェクト間の連携も可能な強力な継続的インテグレーションツールです。
複数プロジェクトパイプラインは、マイクロサービスアーキテクチャを採用しているような、プロジェクト間の相互依存を必要とする大規模な製品に有効です。
クロスファンクショナルな開発チームがクロスパイプライントリガーを使用して、異なるマイクロサービスプロジェクトの複数のパイプラインを起動するデモを用意しました。「Cross-project Pipeline Triggering and Visualization」をご覧ください。
さらにプロジェクト間の相互依存関係を含めた、パイプライン全体の可視化も可能です。
ユースケース
WebアプリをGitLabの異なるプロジェクトからデプロイするとします。
- 1つは無料版で、アプリをビルドしてテストする独自のパイプラインを持っています。
- 1つは有料版アドオンのためのもので、ビルドとテストを無視します。
- 1つはドキュメント用で、SSGを使用したビルド、テスト、デプロイを行います。
複数プロジェクトのパイプラインでは、3つのプロジェクトのすべてのビルドおよびテストステージを含むパイプライン全体を可視化できます。
複数プロジェクトのパイプライン可視化
プロジェクトにGitLab CI/CDを設定すると、ジョブのステージをパイプライングラフで可視化できます。
マージリクエストウィジェットでは複数プロジェクトのパイプラインのミニグラフが表示され、ホバーリングやタップ(タッチスクリーン端末の場合)すると、拡大したり隣接して表示できます。
APIにより起動する複数プロジェクトのパイプライン
- 複数プロジェクトのパイプラインでの
CI_JOB_TOKEN
の使用は、GitLab Premium9.3で導入されました。- 複数プロジェクトのパイプラインでの
CI_JOB_TOKEN
の使用は、GitLab 12.4ですべての階層で可能になりました。
CI_JOB_TOKEN
を使ってパイプラインを起動すると、GitLabはジョブトークンのソースを認識してこれらのパイプラインを内部的に結びつけ、パイプライングラフでその関係を可視化できます。
これらの関係は、上流と下流のパイプラインの依存関係を示すインバウンドとアウトバウンドの接続を示すことで、パイプライングラフに表示されます。
.gitlab-ci.yml
からの複数プロジェクトのパイプラインの作成
- GitLab Premium11.8で導入されました。
- 12.8ですべての階層で利用可能になりました。
ブリッジジョブによるダウンストリームパイプラインの起動
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
ジョブがテスト
段階で成功するとすぐにstaging
bridgeジョブが開始されます。このジョブの初期状態はpending
です。GitLabはmy/deployment
プロジェクトに下流のパイプラインを作成し、パイプラインが作成されるとすぐにstaging
ジョブが成功します。my/deployment
は、そのプロジェクトへのフルパスです。
上流のパイプラインを作成したユーザーは、下流のプロジェクト(
ここではmy/deployment
)へのアクセス権を持っている必要があります。下流のプロジェクトが見つからない場合、またはユーザーがパイプラインを作成するためのアクセス権を持っていない場合、staging
ジョブは_失敗した_ものとしてマークされます。
staging
が成功したと表示されます。代わりに下流のパイプラインのステータスを表示したい場合は、「起動されたパイプラインからのミラーリング状況」を参照してください。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
ジョブに渡され、すべての下流のビルドのコンテキスト内で利用できるようになります。
起動されたパイプラインからのミラーリング状況
- GitLab Premium12.3で導入されました。
- 12.8でGitLab Coreに移行しました。
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
andexcept
-
when
(on_success
、on_failure
、always
の各値のみ) extends
上流のプロジェクトが再構築されたときにパイプラインを起動する
GitLab Premium12.8で導入されました。
別のプロジェクトで新しいタグのパイプラインが終了したときに、自分のプロジェクトのパイプラインを起動できます。
- プロジェクトの 「設定」>「CI/CD」ページに移動し、「パイプラインのサブスクリプション」セクションを展開します。
- 購読したいプロジェクトのパスを入力します。
- 購読するをクリックします。
サブスクライブしたプロジェクトの新しいタグに対して正常に完了したパイプラインは、現在のプロジェクトのデフォルトブランチ上のパイプラインを起動するようになりました。アップストリームパイプラインのサブスクリプションの最大数は、アップストリームプロジェクトとダウンストリームプロジェクトの両方で2です。