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

Question

我在我的工作场所开始学习詹金斯。我们对Teamcity使用语义版本控制，我想在Jenkins上实现同样的功能。当我将工件存储在builds文件夹（$JENKINS_HOME/jobs/$JOB_NAME/builds/$BUILD_NUMBER）中时，出现了我的问题，因为JENKINS仅使用BUILD_NUMBER为BUILD创建文件夹，因此当我必须重置反BUILD_NUMBER时，未来工件将存储在以前版本的文件夹中。

例如：

我已经建立了1.3.1_开发。1存储，当我重置版本号时，下一个版本应为1.3.2。1，并应存储在build 1.3.1\u develop的文件夹1中。1.

我的问题是，如果有人能解释我如何处理jenkins上的自动语义版本控制，因为我们重置了构建编号，增加了mayor、minor和patch编号。

詹金斯版本：2.89.4作业--

谢谢你的帮助。

Answer 1

有一个工具GitVersion，它可以满足您的需要，并且可以与Jenkins或其他CI集成。

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

Answer 2

我注意到的第一件事是您没有正确使用语义版本控制<代码>1.3.1\u开发。1应为1.3.1-development 1。生成元数据的前面应始终加上“”符号，并且不会被分解到SemVer排序顺序中。

第二，构建编号永远不会“重置”，它可能最终会滚动，但永远不应该重置。除非只有一个版本号，否则不表示执行版本的机器的版本号通常也是无用的。

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

除了任何构建计数器之外，我建议在构建元标记中使用SHA-1或更好的构建输入散列（例如Git commit Id），并将其用作输出目录名。您仍然可以在prerelease标记上使用单调计数器，但是为了保持唯一性，您必须创建一个包含整个semver字符串的生成输出目录名。

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