Hudson は、Maven ビルド ジョブでプライベート ローカル リポジトリを利用するオプション、または Maven インストールの共通リポジトリ (つまり、他のビルド ジョブと共有されるリポジトリ) を使用するオプションを提供します。私たちのビルドは、クリーン ビルドであることを保証するためにプライベート ローカル リポジトリを使用する必要があると感じています。ただし、これにより、特に各ジョブのすべての依存関係をダウンロードする帯域幅に関して、パフォーマンスの問題が発生します。また、クリーンな「ワークスペース」で開始するようにジョブが構成されています。スペースを構築します。
毎日の継続的インテグレーション ビルドの場合、ビルド ジョブごとにプライベート ローカル Maven リポジトリを使用するかどうかを選択することの長所と短所は何ですか? ローカル レポジトリを他のジョブと共有することは大したことですか?
ジェンキンスのドキュメントを解釈すると、次の場合に使用しprivate Maven repositoryます
- POM のどのリポジトリにもそれらがない可能性があるという事実にもかかわらず、ローカルリポジトリにすべての依存関係があるという理由だけで、ビルドが誤って成功することになります。
- 同時 Maven プロセスが同じローカル リポジトリを使用しようとすることに関して問題があります。
さらに
このオプションを使用する場合は、リモートの Maven リポジトリーに頻繁にアクセスする必要がないように、Maven 成果物マネージャーをセットアップすることを検討してください。
また、(ワークスペースのクリーンではなく) scm のクリーン オプションを調べて、このリポジトリが核にならないようにすることもできます。
Sonatype はローカルの Nexus インスタンスを使用することを推奨していると思いますが、独自の調査 (State of the Software Supply Chain report 2015) では、Maven Central へのトラフィックの 5% 未満がそのようなリポジトリからのものであることが示されています。
質問に戻ると、ローカルの Nexus インスタンスと、ビルド サーバー (Jenkins など) と Nexus の間に高帯域幅の接続 (少なくとも数十 Gbps) があると仮定すると、プライベート ローカル リポジトリを使用することの欠点はほとんど見られません。実際、ビルド パフォーマンスの低下は合理的なトレードオフと言えます。
上記で述べたように、正確には何をトレードオフしているのでしょうか? プロキシが機能するため、ローカルの Nexus インスタンスに対して、独立したクリーンなビルドが 100% の確実性でわかっているマイナス面とプラス面で、わずかなパフォーマンスの低下を受け入れています。
ビルド サーバー上のローカル リポジトリ (おそらくジェンキンスのユーザー ホーム ディレクトリ内) に、Nexus にキャッシュされていないアーティファクトがあるシナリオを考えると、後者は重要です (Maven Central に対してビルドを開始した場合、これはありそうもないことではありません)。 . この非同期シナリオは、Nexus のキャッシュ TTL 設定が、Nexus の Central へのアップストリーム接続が一時的にダウンした場合にビルドが失敗することを意味するシナリオになる可能性があるため、最適ではありません。
最後に、トレードオフのメリットをさらに高めるために、今日は共有 Jenkins ユーザー .m2/repository でアーティファクトを取得するのに何時間も費やしました。その日の早い段階で、Central へのアップストリーム接続がローカルで何時間もアップダウンしていました (エンタープライズ コンテキストでの不可解な問題)。最後に、共有されたjenkinsユーザー.m2/repository全体を削除して、すべてローカルNexusから取得できるようにしました。
ローカルの .m2/repository (jenkins ユーザーのホーム ディレクトリ内) を使用したビルドと、プライベート ローカル リポジトリを使用したビルド (高速ビルドおよび低速ビルド) を検討する価値があります。ただし、私の場合は、最初のインスタンスでのみプライベート ローカル リポジトリを選択する場合があります。ぶら下がっている成果 (マルチ モジュール ビルドの分割など) に焦点を当ててビルドを最適化すれば、ペナルティを受け入れることができる場合があります。