We are using Jenkins Pipeline Multibranch Plugin with Blue Ocean.
Through my reading, I believe it is quite common to tie your project's build number to the Jenkins run, as this allows traceability from an installed application through to the CI system, then to the change in source control, and then onto the issue that prompted the change.
The problem is that for each branch, the run number begins at 0. For a project with multiple branches, it seems impossible to guarantee a unique build number.
Maybe instead of a unique (global numeric) build number you might want to try a unique (global) build display name?
According to "pipeline syntax: global variables reference"
currentBuild.displayName
is a writable property. So you could e.g. add additional information to the build number (in order to make it globally unique) and use that string in subsequent artifact/application build steps (to incorporate that in the application's version output for your desired traceability), e.g. something like:Using the build's schedule or start time formatted (
currentBuild.timeInMillis
) as a readable date, or using the SCM revision might be also useful, e.g. resulting in "20180119-091439-rev149923".See also:
You can get the Git branch name from
$GIT_BRANCH
and add this to$BUILD_NUMBER
to make an ID that's unique across branches (as long as your company doesn't do something like get themselves taken over by a large corporation that migrates you to another Jenkins server and resets all the build numbers: to protect against that, you might want to use$BUILD_URL
).Only snag is
$GIT_BRANCH
contains the/
character, plus any characters you used when naming the branch, and these may or may not be permitted in all the places where you want an ID. ($BUILD_URL
is also going to contain characters like:
and/
) If this is an issue, one workaround would be to delete unwanted characters withtr
:(
-dc
means delete the complement of these characters, soA-Z
,a-z
,0-9
and-
are the characters you want to keep.)