Jenkins の設定を改善しようとしています。これまでのところ、/plugins と /tests の 2 つのディレクトリがあります。
私たちのプロジェクトは、Eclipse プラグインのマルチモジュール プロジェクトです。/tests フォルダー内のテスト プラグインは、/plugins 内の対応する生産的なコード プラグインに依存するフラグメント プロジェクトです。
これまで、/plugins と /tests の両方をチェックアウトし、それらすべてをビルドして Surefire の結果などを生成する Jenkins ジョブは 1 つしかありませんでした。
現在、提供する機能に応じて、プロジェクトをより小さなジョブに分割することを検討しています。私たちが試みた方法は最適ではないようです。
次のことを試しました。
- コア機能のジョブを作成しました。このジョブは /plugins および /tests ディレクトリ全体をチェックアウトし、機能を構成するプラグインのみをビルドします。このジョブには、コア アーティファクトを定義し、機能に含まれるモジュールについて通知する個別の pom.xml があります。
- 機能プラグインで実行する必要があるテスト用に別のジョブを作成しました。このジョブは、コア ジョブから複製されたワークスペースを使用します。このジョブは、コア機能が構築された後に実行されます。
どういうわけか、これは最適ではないと思います。
- たとえば、チェックアウトされたファイルを更新できるのはコア ジョブだけです。テストのみが更新される場合、コア機能を再構築する必要はありませんが、再構築する必要があります。
- コア機能に依存する機能があるとすぐに、この機能はコア機能ワークスペースのクローンを使用するか、/plugins と /tests の独自のコピーをチェックアウトする必要があり、肥大化につながります。
- 複製されたワークスペースを使用すると、ソースを更新できません。したがって、別の機能に依存する機能がある場合、コア機能が更新されて構築されている場合にのみ、その仕事を行うことができます。
ここにはいくつかの基本的なものが欠けていると思います。誰か助けてくれませんか？これには間違いなくもっと簡単な方法があります。
編集:すべてが機能した場合に理想的に起こると思うことを定式化しようとします:
- 機能コンポーネントが変更されたかどうかを確認します (つまり、それらの更新が可能です)。
- 変更された場合は、機能をビルドします
- 必要に応じて、依存する機能を構築します (つまり、ob 対応するジョブをチェックします)。
- 機能自体を構築する
- ビルドが成功したら、機能テスト ジョブを開始します
- フィーチャー ジョブでテスト ジョブの結果を表示させてください
最後に、プロジェクト ジョブは
- 夜間ビルドを行う
- /plugins と /tests からすべてのソースを確認してください
- すべてビルド、すべてテスト、結果をソナーに送信
さらに、プロジェクトの機能のビルドとテスト結果がプロジェクト ジョブの結果に結合されるため、ナイトリー ビルドが不要であると便利です。
このようなことは可能ですか？