5

この基本的なビルド パイプライン (gradle タスクを使用) を使用します。

  1. 単体テストのコンパイル/実行 (gradle クリーン ビルド)
  2. 統合テスト (gradle integrationTest)
  3. 受け入れテスト (gradle acceptTest)
  4. デプロイ (gradle myCustomDeployTask)

Jez Humble の "Continuous Delivery" book によると、バイナリは 1 回だけビルドする必要があります。したがって、上記の理論的なパイプラインでは、ステップ 1 で WAR をクリーンアップ、コンパイル、ビルドし、ステップ 2 で (ステップ 1 のコンパイル済みコードを使用して) 統合テストを実行し、ステップ 3 で (コンパイル済みコードを使用して) 受け入れテストを実行します。ステップ 1 のコード)、ステップ 4 で (ステップ 1 でビルドした) WAR をデプロイします。ここまでは順調ですね。

このパイプラインを Jenkins に実装しようとしています。各ジョブには独自のワークスペースがあるため、ステップ 2、3、および 4 はコードを再コンパイルして WAR を構築することになります。

これに対抗するために、「Clone Workspace SCM」 Jenkins プラグインを使用しました。これは、最初のビルドからワークスペースを圧縮し、ビルド 2、3、および 4 のワークスペースのソースになります。ただし、gradle はそれぞれのコードを再コンパイルします。ファイルの絶対パスを使用して、タスクを実行する必要があるかどうかを判断するためです。プラグインがファイルを新しいワークスペースに移動したため、絶対パスが変更されたため、gradle はインクリメンタル ビルドを実行するのではなく、最初から開始する必要があると判断しました。

Jenkins でワークスペースを共有できるようになりましたが、共有ワークスペースに対して 2 つのジョブが実行される可能性があるため、これも嫌われています。

では、Jenkins と Gradle を使用して上記のパイプラインを実装し、継続的デリバリー、Jenkins、および Gradle のベスト プラクティスを遵守するにはどうすればよいでしょうか。

4

2 に答える 2

0

私は試していませんが、プロジェクトに以下を追加してみてください:

build.onlyIf { ! Boolean.getBoolean('skip.build') }

引数を指定して gradle を実行する-Dskip.build=trueと、ビルド タスクがスキップされます。

gradle docsのSkipping Tasks セクションを見てください。

これは、このGradle build without testsの質問の回答に似ています 。

于 2013-07-18T17:59:02.213 に答える
0

最初に、後のターゲット (integrationTest など) がコンパイルに依存していないことを確認します。次に、最初のジョブで生成された war ファイルを jenkins アーティファクトとして公開します。次に、コピー アーティファクト プラグインなどを使用して、war ファイルをターゲット ワークスペースにコピーします。

于 2013-07-17T07:33:49.477 に答える