3

最近、ビルド環境に 2 台目のビルド マシンを追加したところ、非常に奇妙なビルド エラーが時々発生するようになりました。

AとBの2 つの別個の Maven ビルド マシンがあり、それぞれ Maven 2.2.1 を実行し、共有の Nexus 1.5.0 リポジトリ マネージャーと通信しています。私の問題は、以前にAによってビルドされ、Nexus にアップロードされた共通の依存関係 ' acme-1.0.0-SNAPSHOT 'の新しいバージョンのダウンロードを拒否するため、 Bでのビルドが失敗することがあるということです。

両方のマシンのローカル リポジトリを調べたところ、リポジトリ メタデータに奇妙な点がいくつかありました。

マシンAの acme\1.0.0-SNAPSHOT\maven-metadata-nexus.xml:

<metadata>
  <groupId>acme</groupId>
  <artifactId>acme</artifactId>
  <version>1.0.0-SNAPSHOT</version>
  <versioning>
    <snapshot>
      <buildNumber>1</buildNumber>
    </snapshot>
    <lastUpdated>20100525173546</lastUpdated>
  </versioning>
</metadata>

マシンBの acme\1.0.0-SNAPSHOT\maven-metadata-nexus.xml:

<metadata>
  <groupId>acme</groupId>
  <artifactId>acme</artifactId>
  <version>1.0.0-SNAPSHOT</version>
  <versioning>
    <snapshot>
      <buildNumber>2</buildNumber>
    </snapshot>
    <lastUpdated>20100519232317</lastUpdated>
  </versioning>
</metadata>

Nexus の acme/1.0.0-SNAPSHOT/maven-metadata.xml では:

<metadata>
  <groupId>acme</groupId>
  <artifactId>acme</artifactId>
  <version>1.0.0-SNAPSHOT</version>
  <versioning />
</metadata>

私がメタデータ ファイルを正しく解釈している場合 (オンラインのドキュメントは乏しい)、マシンB は、マシン Bがビルドしてから 6 日後にマシンAが最後にビルドしたという事実にもかかわらず、(buildNumber に基づいて) acme依存関係の新しいバージョンがあると信じているようです。(タイムスタンプに基づく)。また、Nexus は一般的に正しい buildNumber を認識していないようです。

このような状況がどのように発生する可能性がありますか? 一貫性のないメタデータが原因でビルドが失敗しないようにするにはどうすればよいですか? 似たような経験はありませんか？

重要事項:

  • 両方のビルド マシンには、updatePolicy が「常に」である settings.xml ファイルがあります。
  • Nexus には、 Aによってビルドされた新しいバージョンのacmeが実際にあります。Bは単にダウンロードを拒否します。
  • Nexus にアップロードするマシンはAとBだけです。
  • 両方のサーバーが同じシステム時間を共有します。
  • 関連するすべてのプロセスには、必要に応じて更新できるように、メタデータ ファイルへの書き込み権限があります。
  • この動作を説明する未解決の Maven または Nexus の問題は見つかりませんでした。
  • 私たちの CI サーバー (Atlassian Bamboo) は、同じアーティファクトのビルドが同時に発生するのを防ぎます。そのため、Nexus へのアップロード中に競合状態が発生する可能性はほとんどありません。
4

2 に答える 2

2

Nexusから間違ったmaven-metadataを投稿したようです。これは、acme/1.0-SNAPSHOTフォルダーではなくacmeフォルダーにあるもののようです。（ビルド番号とタイムスタンプが含まれています）。

とにかく、Mavenビルドコマンドに-Uを追加してみましたか？常に設定を尊重するMavenのバグに遭遇した可能性がありますが、-Uは機能すると確信しています。

于 2010-06-06T01:54:40.917 に答える
2

しばらく時間がかかりましたが、根本的な問題を突き止めてバグMNG-4142を突き止めました。

何が起こったかは次のとおりです。

私のacme-1.0-SNAPSHOT (ビルド 1) はAにインストールされ、Nexus にアップロードされました。プロジェクトは次にBでビルドされ、新しくビルドされたacme-1.0-SNAPSHOT (ビルド 2) がインストールされ、ビルド 1 をオーバーライドして Nexus にアップロードされました。

次に、依存関係としてacme-1.0-SNAPSHOTを持つ Aマシンでビルドが発生すると、MNG-4142 が発生しました。リポジトリ メタデータには「true」が含まれていたため、A は acme-1.0-SNAPSHOT の最新のビルド 2 をダウンロードできませんでした。、したがって、maven はビルドの失敗を引き起こした古いビルド 1 に対して私のプロジェクトをビルドしました。-U が使用された場合でも、これは依然として当てはまりました。

この問題について述べたように、私はこの動作に非常に驚いており、このバグが存在する中で他の分散ビルド環境がどのように機能するかを考えるのに苦労しています. 現在、「localCopy」メタデータを false に頻繁に変更するいくつかの cron ジョブを使用して、デフォルトの正しい動作であると思われるものを取得しています。

于 2010-06-07T15:47:58.890 に答える