現在、Jenkins 2.0 のパイプライン アプローチをテストして、使用しているビルド環境で機能するかどうかを確認しています。
まず環境そのものについて。現在、複数の SCM リポジトリで構成されています。各リポジトリには、開発のさまざまな段階に対応する複数のブランチが含まれており、各ブランチは複数の構成でビルドされています。すべての構成がすべてのリポジトリに適用されるわけではありません。
現在、すべてのリポジトリ/ブランチは、さまざまな構成のマトリックス プロジェクトとしてセットアップされています。各プロジェクトはそのビルド結果をアーティファクトとして公開し、これらのアーティファクトは下流のプロジェクトで使用されます。
異なるリポジトリは相互に依存しているため、アップストリーム ジョブでビルドが成功すると、特定のダウン ストリーム ジョブがトリガーされます。現在のところすべて機能していますが、多くの異なるプロジェクトを手動で変更する必要があるため、新しいブランチのセットアップやビルド プロセスの微調整に必要な作業量は膨大です。
ここで、新しいパイプラインを試してみたいと思いました。私のアイデアは、マルチブランチ パイプライン プロジェクトを作成Jenkinsfile
し、ビルドの指示を含むリポジトリ内に配置することでした。
主な問題は、基本的に特定の上流ブランチのビルドが下流ブランチをトリガーする必要があるため、ビルドを相互にトリガーすることです。どのダウンストリーム ブランチをトリガーする必要があるかという情報は、アップストリーム プロジェクトには知られていません。各ダウンストリーム プロジェクトは、いくつかのアップストリーム ブランチからアーティファクトを取得します。理想的なソリューションは、アーティファクトのソースであるアップストリーム ビルドがビルドを終了した場合にダウンストリーム ビルドがトリガーされる場合です。
問題は、下流のプロジェクトだけが必要なアーティファクトを本当に知っているということです。ほとんどの場合、ブランチ名が一致する可能性は低いため、上流のプロジェクトからビルドをトリガーすることは非常に困難です。
現在、これは を使用して解決されていReverseBuildTrigger
ます。しかし、これはパイプラインに近づくとすぐに機能しなくなります。
これを機能させる方法は本当に途方に暮れています。ReverseBuildTrigger
パイプライン スクリプト内で動作するようなものを取得する方法はありますか?
また、単一のブランチの上流が変更された場合に、すべてのブランチの下流のビルド全体をトリガーすることはオプションではありません。これにより、非常に多くの同等のビルドが作成されます。