5

マスター git ブランチに maven ビルドの目標 'clean package deploy' を使用する Jenkins ジョブがあります。ただし、nexus リポジトリが再デプロイを許可していないため、バージョンを変更せずに Jenkins ジョブを 2 回実行すると、予想される 400 Bad Request エラーで失敗します。

org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal 
    org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) 
    on project common-library: 
Failed to deploy artifacts: Could not transfer artifact 
    net.bacon.common:common-library:pom:1.2.13 from/to bacon-releases 
    (https://maven.bacon.com/nexus/content/repositories/releases): 
Failed to transfer file: 
    https://maven.bacon.com/nexus/content/repositories/releases/net/bacon/common/common-library/1.2.13/common-library-1.2.13.pom. 
Return code is: 400, ReasonPhrase:Bad Request.

Jenkinsジョブを失敗させることなくデプロイ目標を実行できる別の戦略を提案できる人はいますか?

4

5 に答える 5

4

私たちがしているのは、自動スナップショット ビルドです。その後、バージョンは自動的にインクリメントされます。

リリース ビルドでは、maven リリース プラグインを使用し、バージョンを手動で入力します。ただし、リリース プラグインに作業を任せることはできます。「-SNAPSHOT」ビルドを削除してデプロイし、次のリリース バージョンでは最後の桁を増やして「-SNAPSHOT」を再度追加します。

ディストリビューション管理の場合、スナップショット用とリリース用の 2 つのリポジトリを異なる再デプロイ設定で使用できます。

于 2013-04-22T13:51:18.083 に答える
1

「ダブルアクション」ソリューションを適用します。

  • 増分バージョン
  • mvn install を実行します
  • テストを実行する
  • すべて合格したら、mvn deployを実行します

このようにして、すべてが合格したことを確認する前に展開しようとすることはなく、毎回一意のバージョンが展開されます。

これが役立つことを願っています。

于 2013-07-09T06:24:40.120 に答える
0

これは私たちのグループの問題でもあります。

Maven に PASSIVE デプロイを試行してもらいたいので、デプロイが nexus に存在する場合は、正常にデプロイされて SUCCESS ALREADY DEPLOYED に進み、デプロイが nexus に存在しない場合はアップロードされ、SUCCESS でデプロイされます。

ジェンキンスをビルドしてカバレッジチェックに合格した後にデプロイしたいのですが、デプロイされていないものだけがデプロイされ、デプロイ済みのものは無視されるようにする方法。

私たちのソリューションは、カスタム スクリプトでした。

于 2013-07-08T23:23:07.313 に答える
0

マスターの各コミットが pom ファイルに独自のバージョン番号を持っていることを確認する必要があります。したがって、再デプロイはありません。

「再デプロイ」を拒否するのには十分な理由があります。リリースされたバージョンのコンテンツは決して変更されるべきではありません。

マスターで同じバージョン番号のコミットを避けることができない場合は、チェーンされた jenkins ジョブを「クリーン インストール」(アーティファクトをローカル リポジトリにのみ保存する) に変更し、開始されるだけの「クリーン デプロイ」で新しいジョブを作成することを検討してください。手動で。

于 2013-04-22T14:05:05.583 に答える