如何在 Jenkins 上处理语义版本控制答案

【问题标题】：How to deal Semantic Versioning on Jenkins如何在 Jenkins 上处理语义版本控制
【发布时间】：2018-08-25 05:51:03
【问题描述】：

我开始在工作场所使用 Jenkins。我们在 Teamcity 中使用语义版本控制，我想在 Jenkins 上实现同样的功能。当我将工件存储在构建文件夹 ($JENKINS_HOME/jobs/$JOB_NAME/builds/$BUILD_NUMBER) 中时出现我的问题，因为 Jenkins 仅使用 build_number 来创建构建文件夹，因此当我必须重置 de Build_number 时，未来的工件将是存储在以前版本的文件夹中。

例如：

我已经存储了构建 1.3.1_develop.1，当我重置 Build_Number 时，下一个构建应该是 1.3.2_develop.1，它应该存储在构建 1.3.1_develop.1 的文件夹 1

我的问题是，是否有人可以解释我如何处理 jenkins 上的自动语义版本控制，因为我们重置了内部版本号，我们增加了市长、次要和补丁号。

詹金斯版本：2.89.4 Jobs--> 我们使用 Jobs 来编译 Vuejs for front 并用 python 部署回来（如果这有帮助）

感谢您的帮助。

【问题讨论】：

您的构建系统是确定性的吗？它是否总是为每组固定的输入产生完全相同的输出？
不，我的构建系统创建的文件夹的 Build_number 总是在增加，但我重新设置了数字以重新开始。（詹金斯就是这样做的）

标签： jenkins continuous-integration semantic-versioning

【解决方案1】：

我注意到的第一件事是您没有正确使用语义版本控制。 1.3.1_develop.1 应该是 1.3.1-develop+1。构建元数据应始终以加号“+”开头，并且不计入 SemVer 排序顺序。

其次，内部版本号永远不会“重置”，它最终可能会翻转，但绝不应该重置。不表示执行构建的机器的构建号通常也是无用的，除非永远只有一个。

基本上，语义版本控制中没有内部版本号的概念。该标准指定了构建元数据的语法，但对可能包含的内容完全中立。在语义版本控制级别上，内部版本号通常是无用的。它们用于防止 CI 构建系统中的目录冲突，甚至为某些产品线（例如 Windows）提供唯一标识符，特别是在不使用语义版本控制的情况下（再次是 Windows）。

除了任何构建计数器之外，我建议在构建元标记中使用构建输入的 SHA-1 或更好的哈希值（例如 Git 提交 ID），并将其用作输出目录名称。您仍然可以在预发布标签上使用单调计数器，但您必须创建一个包含整个 semver 字符串的构建输出目录名称，以保持唯一性。

第三，您的构建机器是归档构建工件的最糟糕的地方！构建自动化有时会而且确实会出现可怕的错误。您的构建系统不应访问您的构建工件存档。当您的构建和初始冒烟测试完成时，它应该发出一个在完全不同的机器上运行的进程的信号，以将工件从构建机器上移到更安全的位置。构建系统上运行的任何进程都不应拥有对构建工件存档的写入权限。

【讨论】：

首先感谢您的回答。我们还将成功构建存储在谷歌机器中的其他地方，你知道是否有任何方法可以在詹金斯构建中链接到谷歌机器中复制的版本？我想访问 jenkins 中的最后一个版本，我不知道这是否是正确的方法，但在 Teamcity 中，我们可以访问 20 个最后的版本。您谈到使用计数器，这应该对我有帮助，但是有一种方法可以自动增加该计数器？抱歉，如果问“愚蠢”的问题，但詹金斯对我来说是新的，我真的很困惑
Jenkins 只是另一个我不想知道的随机 CI 环境。我可以帮助您了解 SemVer 和一般 CI 流程/模式，但不能提供详细信息。如果 Jenkins 没有对您想做的事情的内置支持，您可以随时为其编写脚本。使用文件中的数字来实现计数器相当简单。

【解决方案2】：

有一个工具 GitVersion 可以做你想做的事，它可以与 Jenkins 或其他 CI 集成。

https://gitversion.readthedocs.io/en/latest/build-server-support/build-server/jenkins/

【讨论】：