Maven 发布插件以及 ci 友好版本

Question

我只是设置一个 Maven 多模块项目，其${revision}版本如https://maven.apache.org/maven-ci-Friendly.html中所述

该属性${revision}在父 POM 中设置，并在所有模块中用作版本号。

这对于 SNAPSHOT 构建来说效果很好，但是当我运行 Maven 发布插件时，版本会被替换为类似于1.0.0然后的内容1.0.1-SNAPSHOT。因此，ci 友好版本在发布后就消失了。

有没有办法以不破坏ci友好版本的方式配置Maven发布插件？

Answer 1

CI 友好版本方案旨在取代Maven Release Plugin，而不是补充它。在当今的开发世界中，大多数团队都依赖 CI 服务器进行集成测试、执行自动化测试以及持续交付或持续部署的发布。当一切都可能是 a 时， a 的概念SNAPSHOT就真正受到限制SNAPSHOT。

基本思想是版本中使用的值将在构建时从DVCS（Git、SVN等）和CIS（Jenkins、Travis CI、GitLab等）收集，并用于修改或设置 POM/发布版本。这些值包括内部版本号、缩短的 Git 哈希值或其他任何值。

实施 CI 友好 Maven 构建的过程：

Maven仅支持标签中的少数属性<version>。这些是${revision}、${changelist}和${sha1}。
您可以使用硬编码值和可接受的属性，或者只是使用类似${revision}. 注意：我现在推荐${revision}.
在中<properties>，将值设置为可接受的默认值——可以清楚地看出它们来自非构建机器的假值，例如0构建号。
在中<properties>，从其他属性和硬编码值中组装的值<revision>，例如版本。例如，<revision>1.0.0b${changelist}-${sha1}</revision>。
在构建时，使用-D标志来设置实际值。例如，该${BUILD_NUMBER}值被注入到每个 Jenkins 构建中 -- -Dchangelist=${BUILD_NUMBER}。
您现在可以灵活地更改版本号组件。

在 CI 管道中，您现在可以检测提交分支并master通过清除全部或部分这些值来执行发布。例如，功能分支可以计算并添加 Git 哈希值。语义版本在上面设置——开发人员现在拥有并控制它。他们必须知道自己的代码才能进行更改，并且可以自由地增加语义版本。这是非常宝贵的灵活性。

不过，这里合理的推理是加快速度并摆脱重量级流程，该流程实际上几乎没有添加将代码与其精确来源联系起来的相关信息。通过使用 CI 友好版本，您将让部署人员、测试人员和系统管理员看到编译号和代码提交哈希，从而使问题与实际代码发布精确相关。

应该指出的是，这需要一定的哲学灵活性来接受范式转变。改变是好的，放弃发布插件将使你的发布管道变得更好。