いくつかの「ジョブ」を持つCloudBeesプロジェクトがあります。これらのジョブの一部は、個別に更新される個別のGoogleプロジェクトに対応しています。
私たちの問題は、すべての更新が同じスナップショットリポジトリに送られることです。したがって、2人の開発者AとBが同じプロジェクトに取り組んでいて、Aが変更をプッシュしているときに、Bは最新バージョンを取得します。
理想的には、Googleプロジェクトごとに1つのスナップショットリポジトリを作成して、互いに重複しないようにします。
同じCloudBeesプロジェクトで異なるスナップショットリポジトリを作成し、それらを異なるプロジェクトに関連付けるにはどうすればよいですか？
プロジェクトごとに異なるスナップショット リポジトリを本当に使用したい場合は、ジョブごとに「プライベート ローカル リポジトリ」機能を使用して、ジョブが独自のスナップショット リポジトリから依存関係をプルしていることを確認する必要があります。
さらに、各ジョブに個別の settings.xml を提供する必要があります。そうしないと、とにかく同じリモート リポジトリから依存関係を取得することになります。
次に、Forge Repositories 画面を使用して、CloudBees サービスに別の Maven WebDAV リポジトリを作成する必要があります。無料利用枠を利用している場合、Maven WebDAV リポジトリの数が制限に達している可能性があることに注意してください。ごまかす可能性があります。リポジトリ パスが実際にはパスのサブパスであることを settings.xml に伝えます。 /repositories/snapshot/project2ではなく、https: //user1650693.forge.cloudbees.com/repositories/snapshot
これは基本的に、project1 と project2 が完全に別のリモート リポジトリを参照することを意味します。
これはすべて、あなたに代わって多くの作業を行うことです....そして管理するのは大変な作業です....そして、Mavenで多くの回避策を実行していると、間違ったことをしていると大声で叫びます!
おそらく、一時停止して、Maven アンチパターンを呼び出している場所を考えて、そのアンチパターンから離れる必要があるかもしれません。
私がよく目にするアンチパターンの 1 つは、verify自分が何をしているのか理解していないフェーズを過ぎてビルドを実行することです。
deploy一般に、開発者を台無しにするため、非リリース ビルドでは CI システムを実行しないことをお勧めします... [deploy回避策は、CI システムのみが使用する別の -SNAPSHOT リポジトリを実行することです]
verifyこれが、各ジョブに独自のプライベート Maven リポジトリが必要な場合と同じように、CI システムまでしか行かないことを好む理由installです...ただし、ジョブを少しずつ分割するためにそこまで行く必要がある場合もあります.
経験則では、開発者のマシンには開発者が構築した依存関係が必要であり、Maven の更新のランダムな気まぐれで更新を取得しないようにする必要があります。settings.xml
Mavenの観点から、シナリオでは、Bが「最後の安定バージョン」を取得したくない場合はASNAPSHOTに依存しないでください。
「プライベートローカルリポジトリ」の詳細オプションを使用して、jenkinsジョブのMavenローカルリポジトリを分離することもできます。これにより、Bは、最後にビルドされたバージョンではなく、最後に公開されたバージョンのBのみを表示します。