java - Maven 发布插件和 cifriendly 版本
问题描述
我只是设置一个 Maven 多模块项目,${revision}
其版本如https://maven.apache.org/maven-ci-friendly.html中所述
该属性${revision}
在父 POM 中设置,并在所有模块中用作版本号。
这适用于 SNAPSHOT 构建,但是当我运行 Maven 发布插件时,版本会被替换为1.0.0
then之类的东西1.0.1-SNAPSHOT
。所以 cifriendly 版本在一个版本之后就消失了。
有没有办法以不破坏 cifriendly 版本的方式配置 Maven 发布插件?
解决方案
CI 友好版本方案旨在替换Maven 发布插件,而不是对其进行补充。在当今的开发世界中,大多数团队都依赖 CI 服务器进行集成测试、执行自动化测试以及通过持续交付或持续部署发布。当一切都可能是 a 时, a 的概念SNAPSHOT
确实是有限的SNAPSHOT
。
值得注意的是,发布插件执行的进程是正确实施的 CI 友好配置的 4 到 5 倍。想象一下,使用发布插件的 50 分钟构建变成使用 CI 策略的 15 分钟构建。现在是现代化!
基本思想是版本中使用的值将在构建时从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 友好版本,您可以让部署人员、测试人员和系统管理员看到编译号和代码提交哈希,从而使问题与实际代码版本精确相关。
应该注意的是,这需要一点哲学上的灵活性来接受范式转变。改变是好的,放弃发布插件会让你的发布管道更好。
推荐阅读
- python-3.x - 使用 aiohttp 创建非阻塞 RESTful 服务
- scala - scala.util.Try 递归函数抛出编译错误
- javascript - 如何将类构造函数的前一个实例的参数传播到另一个实例
- c# - Unity:卡住,当一轮完成时准确告诉 GameManager 的问题(所有敌人被杀死)
- c# - 高效快速地读取 Windows 日志
- javascript - 使用无效数据调用的函数 DocumentReference.set()。不支持的字段值:未定义(在字段 firstName 中找到)
- python - 如何通过带有图片的 HTML 重新创建网页
- ansible - Azure Stack 和 Ansible
- javascript - 检测新的鼠标滚轮事件
- reactjs - 在 reducer 中使用重选选择器