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

Question

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

例如：

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

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

Jenkins 版本：2.89.4 作业--> 我们使用作业为前端编译 Vuejs 并使用 python 部署（如果这有帮助）

谢谢你的帮助。

Answer 1

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

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

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

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

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