- ユースケース
- マルチプロジェクトパイプラインの可視化
- 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
ジョブがtest
ステージで成功するとすぐに、staging
ブリッジジョブが開始されます。このジョブの初期ステータスは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 がジョブを選択するときに、環境変数として利用できるようになります。
以下の設定では、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
ジョブに渡され、すべてのダウンストリームビルドのコンテキスト内で使用できるようになります。
起動されたパイプラインからのミラーリング状況
- 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
とexcept
-
when
(on_success
,on_failure
,always
の値のみ) extends
上流のプロジェクトが再構築されたときにパイプラインを起動する
GitLab Premium12.8で導入されました。
別のプロジェクトで新しいタグのパイプラインが終了したときに、自分のプロジェクトのパイプラインを起動できます。
- プロジェクトの 「設定」>「CI/CD」ページに移動し、「パイプラインのサブスクリプション」セクションを展開します。
- 購読したいプロジェクトのパスを入力します。
- 購読するをクリックします。
サブスクライブしたプロジェクトの新しいタグに対して正常に完了したパイプラインは、現在のプロジェクトのデフォルトブランチ上のパイプラインを起動するようになりました。アップストリームパイプラインのサブスクリプションの最大数は、アップストリームプロジェクトとダウンストリームプロジェクトの両方で2です。