Jenkins管道的全球内部版本号

时间:2018-09-06 10:04:45

标签: jenkins jenkins-pipeline

我们正在为构建管理环境从VSoft Continua CI切换到Jenkins。当我们使用经过稍微修改的Gitflow流程时,我们希望Jenkins能够从任何功能,发行版或修补程序分支和拉取请求中进行构建,因此我们决定选择Jenkins Pipeline。

release和hotfix分支的内部版本号基于分支名称(例如release / 2.1.0),而其他任何分支或请求请求的内部版本号均基于日期(例如2018年9月6日解析为18.9) .6)。 Continua CI在所有构建配置中提供了一个自动递增的构建编号,这就是为什么我们使用此构建编号作为构建编号的最后一部分(例如2.1.0.10、18.9.6.11、2.1.0.12等)的原因。使用此版本号作为.NET二进制文件的文件版本和程序集版本,此生成的版本号作为参数传递给MSBuild。

我正在詹金斯(Jenkins)寻找类似的解决方案。 Jenkins管道为每个分支和拉取请求分配一个单独的自动增量构建编号,这可能导致来自不同分支的两个构建具有相同版本。我已经尝试使用全局环境变量来存储版本并在每次构建时增加其价值,但是似乎无法通过管道任务设置全局环境变量。

Jenkins Pipeline项目是否可以在所有分支/拉动请求中共享内部版本号?

1 个答案:

答案 0 :(得分:0)

以下是一些想法:

  • 基于该文件:让您的阶段在.check节点上执行;选择一个文件并确定格式(属性文件可以是一个很好的开始); lockread,更新,编写unlock

  • 将其委托给外部服务(例如,具有 您用于request ID的REST端点)。

  • 为此编写一个插件。