maven 的 buildNumber 元数据如何在多个构建代理之间变得不一致？

Posted 2023-02-26

【中文标题】maven 的 buildNumber 元数据如何在多个构建代理之间变得不一致？

【英文标题】：How might maven's buildNumber metadata become inconsistent across multiple build agents?

【发布时间】：2011-02-24 09:03:00

【问题描述】：

我们最近在我们的构建环境中添加了第二台构建机器，并开始遇到非常奇怪的偶尔构建失败。

我有两个独立的 Maven 构建机器，A 和 B，每个都运行 Maven 2.2.1 并与共享的 Nexus 1.5.0 存储库管理器通信。我的问题是在 B 上构建偶尔会失败，因为它拒绝下载以前由 构建的常见依赖项“acme-1.0.0-SNAPSHOT”的较新版本>A 并上传到 Nexus。

查看两台机器上的本地存储库，我发现存储库元数据中有一些奇怪之处。

机器 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 似乎认为它具有更新版本的 acme 依赖项（基于buildNumber) 尽管机器 A 最后一次构建它是在机器 B 完成后 6 天（基于时间戳）。 Nexus 似乎也不知道一个普遍正确的 buildNumber。

这种情况怎么可能出现？我可以做些什么来防止我的构建由于元数据不一致而失败？你有过类似的经历吗？

重要提示：

两台构建机器都有 settings.xml 文件，其中 updatePolicy 为“always”。 Nexus 确实具有由

A

构建的较新版本的

acme

。

B

只是拒绝下载。

A

和

B

是唯一上传到 Nexus 的机器。 两台服务器共享相同的系统时间。 所涉及的所有进程都具有对元数据文件的写入权限，因此可以根据需要对其进行更新。 我找不到任何描述此行为的开放 Maven 或 Nexus 问题。 我们的 CI 服务器 (Atlassian Bamboo) 可防止同一工件的构建同时发生，因此在上传到 Nexus 时出现争用情况的可能性很小。

【问题讨论】：

edit - 添加了 Nexus 的 maven-metadata.xml 文件。

【参考方案1】：

看起来您从 Nexus 发布了错误的 maven-metadata，这看起来像是 acme 文件夹中的那个，而不是 acme/1.0-SNAPSHOT 文件夹中的那个。 （它会有内部版本号和时间戳）。

无论如何，您是否尝试过将 -U 添加到 maven 构建命令中？您可能偶然发现了一些关于始终设置的 Maven 错误，但我确信 -U 有效。

【讨论】：

感谢您关注我的问题，Brian。我设法找到了我在回答中解释的根本原因。如果我遗漏了什么，请告诉我。

【参考方案2】：

我花了一些时间，但我找到了 maven bug MNG-4142 的根本问题。

事情是这样的：

我的 acme-1.0-SNAPSHOT（构建 1）安装在 A 上并上传到 Nexus。该项目接下来在 B 上构建，其中安装了新构建的 acme-1.0-SNAPSHOT（构建 2）并上传到 Nexus，覆盖构建 1。

然后，当在具有 acme-1.0-SNAPSHOT 作为依赖项的 A 机器上发生构建时，MNG-4142 启动。存储库元数据包含“true " 这阻止了 A 下载 acme-1.0-SNAPSHOT 的更新版本 2，因此 maven 针对导致构建失败的旧版本 1 构建了我的项目。即使使用了 -U，情况仍然如此。

正如我在这个问题上所提到的，我对这种行为感到非常惊讶，并且很难想到其他分布式构建环境在存在此错误的情况下是如何工作的。我们目前有一些 cron 作业经常将“localCopy”元数据更改为 false，以便获得我认为应该是默认且正确的行为。