This plugin creates a new version number and stores it in the environment variable whose name you specify in the configuration.

Configuration

In many cases, the Jenkins build number isn't rich enough to express the information you'd like the version number to have, and generating externally (as part of the build) may not be an optimal solution. This plugin allows you to generate a version number that contains much more information.

Project start date

The version number system has the concept of builds per day / week / month / year / all time. Each of these is the calendar day / week / month / year; that is, all builds in October will have the same build month, all builds in 2009 will have the same build year. These are based on the project start date, which is one of the user-configurable options.

Version Number Format String

The version number format string is processed to create the version number that's stored in the named environment variable. Every character in the version number format string is passed through to the final version number, with the exception of variables enclosed in ${}. For example, the version format string 1.0.${BUILDS_THIS_YEAR}, if this were the 10th build this calendar year, would return 1.0.10.

The following are valid variables for use in the version number format string:

name

function

BUILD_DATE_FORMATTED

Takes the second argument and returns a java-formatted date string for the given build date. For example, ${BUILD_DATE_FORMATTED, "yyyy-MM-dd"} would return the date (and not the time) as something like 2009-10-01. The date format string must be surrounded by quotes, and any whitespace within the format string is significant.

BUILD_DAY

With no arguments, it just returns the day of the build as an integer. If there is an argument, it takes the number of characters in the argument and uses that pad the date string. For example, if it's the third of the month, ${BUILD_DAY} would return 3, ${BUILD_DAY, X} would return 3, and ${BUILD_DAY, XX} would return 03.

BUILD_WEEK

Returns the week, with the same argument convention for BUILD_DAY

BUILD_MONTH

Returns the month, with the same argument convention for BUILD_DAY

BUILD_YEAR

Returns the year, with the same argument convention for BUILD_DAY

BUILDS_TODAY

Returns the number of builds that have happened today, including this one. This resets at midnight. The argument convention is the same as for BUILD_DAY

BUILDS_THIS_WEEK

Returns the number of builds that have happened this week, including this one. This resets at the start of the week. The argument convention is the same as for BUILD_DAY

BUILDS_THIS_MONTH

Returns the number of builds that have happened this month, including this one. This resets at the first of the month. The argument convention is the same as for BUILD_DAY

BUILDS_THIS_YEAR

Returns the number of builds that have happened this year. This resets at the first of the year. The argument convention is the same as for BUILD_DAY.

BUILDS_ALL_TIME

Returns the number of builds that have happened since the project has begun. This is distinct from the hudson build number, in that it can be reset periodically (for example, when moving from 1.0.${BUILDS_ALL_TIME} to 2.0.${BUILDS_ALL_TIME}, and can be configured to start at an arbitrary number instead of the standard begin date.

MONTHS_SINCE_PROJECT_START

The number of months since the project start date. This is strictly dependent on the month of the current build and the month of the project start date; if the project was begun October 31st and the build was November 1st, then this would return 1. If the project was begin October 1st and the build was November 30th, this would also return 1. The argument convention is the same as for BUILD_DAY.

YEARS_SINCE_PROJECT_START

The number of years since the project start date. Like MONTHS_SINCE_PROJECT_START, this is dependent only on the year;

(anything else)

Any other argument enclosed in ${} is replaced by an environment variable of the same name if one is available, or failing that, is just ignored. This can be used to integrate source control version numbers, for example.

Initialization Values

Before the build is started, the number of builds this year / month / week / day can be specified on the command line or via the job's plugin-configuration web-GUI. If they are specified, then they will override whatever values are currently in production. This allows you to migrate your version number from another system to Jenkins if you choose to do so.

Additionally, it is possible to automatically override the number of builds this year / month / week / day with values taken from environment-variables. Instead of just providing a simple number in the form-fields of the job's plugin-configuration which overrides the value for the next build (as described above), you can instead provide an environment-variable whose value will be extracted and used during the next builds. If it is not set or its value is not convertible to a positive integer (without loosing precision), the value of the previous build will be taken instead and increased by one (as is the standard behavior).

Releases

Version 1.9

Release Nov 17, 2017

Accepted merge-request #12. ("Adding functionality to limit the number of characters from a variable.")

NOTE: This changes the checkbox for "skipping failed builds" (which actually meant to not increase the version-number if the former run was not successful) to a combobox of values.The transition works smoothly and does not change the former behavior. However, you should update the configuration of each job that had this checkbox checked (and save it)!(This assures that later updates of this plugin will not break your behavior due to this change.)

IMPORTANT:This might be the last update for this plugin in a long time, because I (user: bahadir) cannot maintain it any longer. Please volunteer to become the new maintainer of this plugin!

I understand we can use the BUILDS_ALL_TIME token to get an incremental build number and reset it manually when we change the major or minor version, but it would be great if this could be automated. I mean having the BUILDS_ALL_TIME reset to one when one of the previous digits in the version string changes.

How can i set build number 3.1.0.3333.1233. 3333 is dynamically changes when baseline the version. This value can be get from xml file. But how can i set it in environment variables. Please help if you have any idea.

We are using the 'Prefix Variable' setting of the plugin to reset the BUILDS_ALL_TIME automatically to 1 when the variable values changes (this is the Mjor.Minor.Patch part of the version for the build, stored in a persistent environment variable parameter).This works great as long as the parameter was set before the version number plugin ran its sequence.

For maven builds, we are trying to get the Prefix Variable parameter from the POM file stored in the SCM (Git), however, though setting the parameter is possible like so, it has no effect on the already set version number.

Is there a way to get the version number plugin to kick in AFTER SCM checkout happens?Or maybe be influenced from 'Prefix Variable' value change no matter when it happens?

How exactly would I set the BUILDS_ALL_TIME to a given number (e.g. I want it to start at 30 instead of 1)?

The page says "it can be reset periodically (for example, when moving from 1.0.${BUILDS_ALL_TIME} to 2.0.${BUILDS_ALL_TIME}, and can be configured to start at an arbitrary number instead of the standard begin date.". I tried via build parameter for BUILDS_ALL_TIME, and via "Prepare an environment for the run -> Properties Content", but it would continue to increment at the current number, not the one I supplied.

At first, I thought I would have access to these any where such as using ${BUILDS_THIS_WEEK) in an EnvInject section. This doesn't seem to be allowed but could be very useful.

So, I wonder if this could be extended to allow more than one variable creation in the same job. It would be way easier to have both 2015.11.01 and well as 20151101 in one job then trying to have both using other methods. Or have a short version 20151101 and a long version with the time attached such as 201511011301.

This will then override the BUILDS_ALL_TIME variable by the value of environment-variable NEW_BUILDS_ALL_TIME; if that environment-variable is not set it will not be overridden. These override* parameters exists for all other counters, too.

That environment-variable should only be available if you really want to reset the value for that counter.If the environment-variable is not available ${NEW_BUILDS_ALL_TIME} will resolve to nothing. Therefore the parameter overrideBuildsAllTime will have an empty string as its value which will not override the normal value.

You can use the example I provided in my former comment. Just make sure that your build-job only sets the environment-variable NEW_BUILDS_ALL_TIME (e.g. via "Prepare an environment for the run -> Properties Content") if you want to override the normal value.

Doing it this way you do not have to adjust the pipeline script anymore if resetting a counter. (This is particularly useful if your pipeline script is under version-control, because you do not have to spam the history with changes just for resetting a counter.)

My problem is that only ver1 gets incremented on the next build and ver2 it's always the previous value. If I move the definition of ver2 before ver1 then ver2 will get incremented on the next build while ver1 will not.

So is this a bug or using two calls in the same pipeline to VersionNumber not supported?

You might ask why I need this - basically ver2 should be different from ver1 and keeps a history of "otherprefix." since it was added.