ダウンストリームパイプラインとは何か？あるパイプラインが別を起動する

ダウンストリームパイプラインとは、別のパイプラインが起動するパイプラインで、job間、あるいは別々のプロジェクト間でさえビルドを連鎖させることができます。

あるパイプラインの終了が別のパイプラインを開始すべき場合があります。共有ライブラリがビルドされ、それに依存するアプリが再ビルドされます。monorepoのコアstageがpassし、サービス固有のパイプラインが起動します。起動されるパイプラインがダウンストリームパイプラインで、それを起動したのがupstreamです。この連鎖は、手動の調整なしに関連するビルドを接続し続けます。

upstreamとダウンストリーム

upstreamパイプラインが最初に実行され、成功時にダウンストリームパイプラインを起動します。ダウンストリームの実行はupstreamから変数やartifactを受け取れるため、盲目的に開始するのではなく、以前に来たものの上に構築します。

パイプラインを連鎖させるべき時

複数のアプリが依存する共有ライブラリ。
1つのプロジェクトが他に供給するマルチプロジェクトのビルド。
高速なコアパイプラインを遅いサービスごとのものから分離する。

簡単な例

GitLabでは、別のプロジェクトを指す trigger: jobでダウンストリームパイプラインを起動します。GitHub Actionsでは、repository_dispatch または workflow_run イベントを使い、終了したworkflowが次を開始するようにします。

ダウンストリーム vs parent-child

ダウンストリームパイプラインは多くの場合別のプロジェクトにあり、parent-childパイプラインは通常同じプロジェクト内で明確さのために分割されています。どちらも実行を連鎖させますが、ダウンストリームはプロジェクト境界を越えることを強調します。

チェーンを可観測に保つ

連鎖したパイプラインは失敗を隠しうます。誰もそれらをリンクしなければ、upstreamの成功がダウンストリームの失敗を覆い隠します。優れたツールはチェーン全体を示すので、起動された実行からその発生源まで問題をたどれます。

重要なポイント

ダウンストリームパイプラインとは、別の（upstream）パイプラインによって起動されるものです。
連鎖は、job間やプロジェクト間で関連するビルドを自動的に接続します。
ダウンストリームの失敗が隠れないよう、チェーン全体を可観測にしましょう。