在 Hudson 的构建目标和标准发布方法中包含“mvn deploy”

Posted 2023-02-27

【中文标题】在 Hudson 的构建目标和标准发布方法中包含“mvn deploy”

【英文标题】：Having 'mvn deploy' in Hudson's build goals and the standard approach of releasing

【发布时间】：2011-05-30 06:03:36

【问题描述】：

我为我的项目设置了 Hudson，构建目标为 mvn clean deploy site:site，每天午夜运行构建，只要有新的更改。

我一直想知道的一件事是我是否应该在构建目标中包含deploy，因为如果我刚刚发布了我的项目的 1.0.0 版（我已将 pom 更改为 1.0.0.0 版），可能会发生这种情况。 0 并提交）但几天以来还没有将版本号增加到 1.0.1-SNAPSHOT，我最终可能会在不同时间部署多个不同的 1.0.0 版本。

但我看到人们在他们的 Hudson 构建目标中使用 deploy - 我想知道他们如何处理这个问题。

实际上使用 Maven 进行发布的正确方法是什么？感谢您的任何指点！

【参考方案1】：

您应该继续从 Hudson 进行自动化的夜间部署，但有关如何处理版本号和发布的更大问题与您的源代码控制系统是错综复杂的。你没有提到你正在使用什么样的源代码控制系统，但我可以解释如何使用 Subversion 来做到这一点。

首先，出于您提到的原因，您应该永远不要将中继中的源代码的版本标识符更改为快照版本以外的任何内容（例如，末尾带有 -SNAPSHOT）。否则，您将在重新部署时覆盖。最佳实践是（临时）将trunk pom（s）中的版本标识符更改为您想要发布的版本，标记trunk，从标签构建，然后部署您从标签构建的构建，然后立即升级主干中的快照版本标识符，最后以更新、更高的快照版本号提交主干。

如果这看起来很麻烦，那么您应该知道 Maven Release Plugin 会依靠 Maven SCM Plugin 与您的源代码控制系统自动完成所有这些工作。

虽然我越来越喜欢从 Hudson 调用 Maven 发布插件，但这是一件非常棘手的事情。为了使其正常运行，这里有一些提示：

实际版本需要由 Hudson 执行，但开发人员可以 当然也可以从他们的 开发机器来测试 发布过程。请务必 删除 Subversion 中的任何标签和任何 在 Nexus 中发布工件 之后。 它使用 maven-scm-plugin，而后者又需要外部 安装的颠覆版本是 在当前路径上。因此版本的 颠覆也必须已经 缓存必要的凭据 写入颠覆源 存储库。 如果发布过程在中途中止，您可以执行 release:rollback 修复 poms，但是 这不会消除任何虚假标签 已经承诺的 颠覆。这些你必须 手动删除，执行 svn 后 更新。 release:rollback 目标有时不返回 pom.xml 版本回到快照。如果 出现任何问题，检查 POM 版本以确保使用“SNAPSHOT”。 release:rollback 目标有时不返回 SCM URL 回到他们原来的位置。如果 出现任何问题，检查这些 指向“主干”或始发 分支。 因为我们使用 Subversion，我们的 maven-release-plugin 配置启用了 suppressCommitBeforeTag 选项 这消除了额外的提交 是否会修改主干 pom.xml 修改之前的文件。

另请注意，有一个Maven Release Plugin integration with Hudson，但不需要从 Hudson 调用 Maven 发布插件目标，它只是让它更容易，但是，我有 no luck 让该插件工作。

总结一下：

仅使用从中继部署 快照 使用 Maven 版本 在一个标签中部署的插件 发布。

希望这会有所帮助。

【讨论】：

关于更改版本并从标签部署 - 这似乎与我在其他地方读到的最佳实践相矛盾：标签是最终版本，因此，不应发生任何更改标签。当您部署/发布 Maven 时，会在生成的 jar 文件中包含修订号。因此，如果您更改版本并在标签中部署，则需要先提交标签中的任何更改，然后发布和部署。不应该这样吗？

这取决于您拥有的源代码控制系统。如果您不更改标签中的版本号，那么您可能必须在主干、提交、标签中更改它，然后立即在主干中修复版本，再次提交 - 从而在您的主干 pom 中留下一些愚蠢的额外提交.幸运的是，使用 Subversion，您可以从本地修改的主干中进行标记！这就是我们通过 Maven Release 插件的 suppressCommitBeforeTag 选项在我们的商店所做的。通过这种方式，标签永远不会被触及，并且在trunk poms中没有额外的提交......一切都可以正常工作。