gpt4 book ai didi

java - Maven 发布插件和 cifriendly 版本

转载 作者:行者123 更新时间:2023-12-04 10:47:23 25 4
gpt4 key购买 nike

我只是用 ${revision} 建立一个 Maven 多模块项目如https://maven.apache.org/maven-ci-friendly.html 中所述的版本

楼盘${revision}在父 POM 中设置并在所有模块中用作版本号。

这适用于 SNAPSHOT 构建,但是当我运行 Maven 发布插件时,版本被替换为 1.0.0然后 1.0.1-SNAPSHOT .所以 cifriendly 版本在一个版本之后就消失了。

有没有办法以不破坏 cifriendly 版本的方式配置 Maven 发布插件?

最佳答案

CI 友好版本方案旨在替换 Maven Release Plugin ,而不是补充。在当今的开发世界中,大多数团队都依赖 CI 服务器进行集成测试、执行自动化测试以及通过持续交付或持续部署发布。 SNAPSHOT 的概念当一切都可能是 SNAPSHOT 时,确实是有限的.
Notably, the Release Plugin executes 4 to 5 times more processes than a properly implemented CI Friendly configuration.想象一下,使用发布插件的 50 分钟构建变成使用 CI 策略的 15 分钟构建。 Now that's modernization!
基本思想是版本中使用的值将从 DVCS 中收集。 ( GitSVN 等)和 CIS ( JenkinsTravis CIGitLab 等)在构建时用于修改或设置 POM/发布版本。这些值是内部版本号、缩短的 Git 哈希值或其他任何值。
实现 CI 友好的 Maven 构建的过程:

  • 马文 supports only a handful of properties<version>标签。这些是 ${revision} , ${changelist}${sha1} .
  • 您可以使用硬编码值和可接受的属性,也可以使用 ${revision} 之类的东西。 . 注意:我现在推荐${revision} .
  • <properties> , 将值设置为可接受的默认值 - 很明显它们来自非构建机器的虚假值,例如 0对于内部版本号。
  • <properties> , 组装 <revision> 的值,例如版本,来自其他属性和硬编码值。例如,<revision>1.0.0b${changelist}-${sha1}</revision> .
  • 在构建时,使用 -D标志来设置实际值。例如,${BUILD_NUMBER}将值注入(inject)到每个 Jenkins 构建中 -- -Dchangelist=${BUILD_NUMBER} .
  • 您现在可以灵活地更改版本号组件。

  • 在 CI 管道中,您现在可以检测提交分支并从 master 执行发布通过清除所有或部分这些值。例如,功能分支可以计算和添加 Git 哈希。语义版本已在上面设置——开发人员现在拥有并控制它。他们必须知道自己的代码才能进行更改,并且他们可以自由地增加语义版本。这是很多宝贵的灵 active 。
    不过,这里的合理推理是加快速度并摆脱一个重量级的过程,该过程实际上几乎没有添加任何将代码与其精确来源联系起来的相关信息。通过使用 CI 友好版本,您可以让部署人员、测试人员和系统管理员看到编译号和代码提交哈希,从而使问题与实际代码版本精确相关。
    应该注意的是,这需要一点哲学上的灵 active 来接受范式转变。改变是好的,放弃发布插件会让你的发布管道更好。

    关于java - Maven 发布插件和 cifriendly 版本,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/59641739/

    25 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com