4

Jenkins の設定を改善しようとしています。これまでのところ、/plugins と /tests の 2 つのディレクトリがあります。

私たちのプロジェクトは、Eclipse プラグインのマルチモジュール プロジェクトです。/tests フォルダー内のテスト プラグインは、/plugins 内の対応する生産的なコード プラグインに依存するフラグメント プロジェクトです。

これまで、/plugins と /tests の両方をチェックアウトし、それらすべてをビルドして Surefire の結果などを生成する Jenkins ジョブは 1 つしかありませんでした。

現在、提供する機能に応じて、プロジェクトをより小さなジョブに分割することを検討しています。私たちが試みた方法は最適ではないようです。

次のことを試しました。

  1. コア機能のジョブを作成しました。このジョブは /plugins および /tests ディレクトリ全体をチェックアウトし、機能を構成するプラグインのみをビルドします。このジョブには、コア アーティファクトを定義し、機能に含まれるモジュールについて通知する個別の pom.xml があります。
  2. 機能プラグインで実行する必要があるテスト用に別のジョブを作成しました。このジョブは、コア ジョブから複製されたワークスペースを使用します。このジョブは、コア機能が構築された後に実行されます。

どういうわけか、これは最適ではないと思います。

  • たとえば、チェックアウトされたファイルを更新できるのはコア ジョブだけです。テストのみが更新される場合、コア機能を再構築する必要はありませんが、再構築する必要があります。
  • コア機能に依存する機能があるとすぐに、この機能はコア機能ワークスペースのクローンを使用するか、/plugins と /tests の独自のコピーをチェックアウトする必要があり、肥大化につながります。
  • 複製されたワークスペースを使用すると、ソースを更新できません。したがって、別の機能に依存する機能がある場合、コア機能が更新されて構築されている場合にのみ、その仕事を行うことができます。

ここにはいくつかの基本的なものが欠けていると思います。誰か助けてくれませんか?これには間違いなくもっと簡単な方法があります。

編集:すべてが機能した場合に理想的に起こると思うことを定式化しようとします:

  • 機能コンポーネントが変更されたかどうかを確認します (つまり、それらの更新が可能です)。
  • 変更された場合は、機能をビルドします
    • 必要に応じて、依存する機能を構築します (つまり、ob 対応するジョブをチェックします)。
    • 機能自体を構築する
    • ビルドが成功したら、機能テスト ジョブを開始します
    • フィーチャー ジョブでテスト ジョブの結果を表示させてください

最後に、プロジェクト ジョブは

  • 夜間ビルドを行う
  • /plugins と /tests からすべてのソースを確認してください
  • すべてビルド、すべてテスト、結果をソナーに送信

さらに、プロジェクトの機能のビルドとテスト結果がプロジェクト ジョブの結果に結合されるため、ナイトリー ビルドが不要であると便利です。

このようなことは可能ですか?

4

1 に答える 1

2

質問の最後から始めます。クリーンなチェックアウト (チェックアウト前に生成されたものをすべて取り除く) を行い、すべてをゼロから構築し、すべてのテストを実行する別の夜間ジョブを保持します。クリーン ビルドを行っていない場合、リポジトリにチェックインしたものが実際にビルドされることを保証できません。

  • 機能コンポーネントが変更されたかどうかを確認します (つまり、それらの更新が可能です)。
  • 変更された場合は、機能をビルドします
    1. 必要に応じて、依存する機能を構築します (つまり、ob 対応するジョブをチェックします)。
    2. 機能自体を構築する
    3. ビルドが成功したら、機能テスト ジョブを開始します
    4. フィーチャー ジョブでテスト ジョブの結果を表示させてください

[1 の「依存機能」とは、2 の「機能」が必要とするものを意味すると想定しています。]

これを行うには、複数の仕事を持っていると言えます。

  • 個々の機能と、その機能を構築するだけのすべての依存機能のジョブ。ジョブは、(従属) フィーチャーの SCM 変更によって開始する必要があります。
  • コンパイル ジョブとは別のテスト ジョブを保持しません。これにより、正常にコンパイルされたコードがテストされない可能性が生じます。代わりに、Jenkins でビルド ステップが失敗した場合、通常はそれ以降のビルド ステップが中止されるという事実に依存します。

コツは、これらすべてをどのように組み合わせるかです。

機能があり、それぞれ独自のビルド ジョブを持つ2 つの依存機能DF1.1およびDF1.2でビルドされるF1と呼ばれるビルド ジョブであるとします。

  • F1のビルドをトリガーするように、 DF1.1DF1.2の両方を構成する必要があります。
  • F1は、最新の成功したDF1.1およびDF1.2ビルドから必要なアーティファクトを取得するように構成する必要があります。残念ながら、非常に優れた「Clone SCM」プラグインは、前の 1 つのジョブからプルするだけなので、ここではあまり役に立ちません。おそらく、アーティファクト パブリッシャー プラグインの 1 つが役立つかもしれませんし、アーティファクトを配置/取得するためにカスタム ビルド ステップを追加する必要があるかもしれません。
于 2012-05-04T14:31:04.673 に答える