Global build number for Jenkins pipeline

1
votes

We are in the process of switching from VSoft Continua CI to Jenkins for our build management environment. As we use a slightly modified Gitflow process we would like Jenkins to be able to build from any feature, release or hotfix branch and pull requests, we decided to go for the Jenkins Pipeline.

The version number for builds from the release and hotfix branches are based on the branch name (e.g. release/2.1.0) while builds from any other branch or pull request is based on the date (e.g. September 6th 2018 resolves to 18.9.6). Continua CI provides a auto increment build number across all build configurations that is why we use this build number as the final part of our build number (e.g. 2.1.0.10, 18.9.6.11, 2.1.0.12, ...). This generated version number is passed as parameter to MSBuild using this version number as the file version and assembly version of our .NET binaries.

I'm looking for a similar solution in Jenkins. The Jenkins Pipeline assigns a separate auto increment build number per branch and pull request which might lead to two builds from different branches having the same version. I already tried using global environment variables to store the version and increase the value with every build but it seems that global enviroment variables cannot be set from Pipeline tasks.

Is there a way for a Jenkins Pipeline project to share a build number across all branches/pull requests?

1
jenkinsjenkins-pipeline
I don't think there is a "built-in" mechanism to do this. It is difficult to try and recommend a specific solution without knowing your job setup (like multibranch, GitHub Organization Folder, etc.). One way that pops in my head immediately is to have a separate job that you call build on from your pipeline, get the number from that, and use it in your build. That job is merely a counter. Not saying it is a good solution, but it is a solution. – mkobit

1 Answers

1
votes

Here are a few ideas:

  • have it file based: have your stage execute on, say, the master node; pick a file and decide on the format (properties file can be a good start); lock, read, update, write, unlock.

  • delegate this to an external service (for instance, a service with a REST endpoint that you use to request an ID).

  • write a plugin for it.