-
Bug
-
Resolution: Won't Fix
-
Minor
-
None
-
Since version 1.597
-
Powered by SuggestiMate
With this release jenkins changed the build identifier to the build number (instead of timestamp). Now the BUILD_NUMBER and BUILD_ID both return the build number and there is no way to get the timestamp from the environment variables.
According to the documentation BUILD_ID should return the timestamp.
BUILD_ID
The current build id, such as "2005-08-22_23-59-59" (YYYY-MM-DD_hh-mm-ss)
Possible fixes:
- Change BUILD_ID to return the timestamp
- Add Env-Var BUILD_TIMESTAMP or similar
- is duplicated by
-
JENKINS-26624 Content of BUILD_ID environment variable changed from timestamp to build number
-
- Resolved
-
-
JENKINS-26679 BUILD_ID not containing build timestamp after 1.597 due to JENKINS-24380
-
- Resolved
-
-
JENKINS-26772 env-vars.html BUILD_ID documentation is incorrect
-
- Resolved
-
- is related to
-
JENKINS-26626 Zentimestamp plugin no longer compatible with Jenkins 1.597
-
- Resolved
-
-
JENKINS-24380 Use build numbers as IDs
-
- Resolved
-
- links to
[JENKINS-26520] Environment Variables BUILD_ID and BUILD_NUMBER now return the same value
BUILD_ID is defined to be the ID of the build, and the ID is now a number rather than a timestamp, so the current behavior is correct. (There are some things in Jenkins which expect a build ID.) Adding a new BUILD_TIMESTAMP variable for the dedicated purpose of representing time is the only option.
I would actually suggest two such variables:
- BUILD_TIMESTAMP_LEGACY, with the format of the old IDs and in the server’s local timezone.
- BUILD_TIMESTAMP, in ISO 8601 format (how-to).
Note that since builds may now come in at a rate of more than one per second, BUILD_TIMESTAMP_LEGACY could easily be nonunique.
For a quick fix (until BUILD_TIMESTAMP was added as an environment variable) use the EnvInject plugin. Enable the "Prepare an environment for the run" option inside your job configuration and paste the following line into the Groovy script section:
return [BUILD_TIMESTAMP:currentBuild.getTime().format("yyyy-MM-dd_HH-mm-ss")]
Take care if you use the zentimestamp plugin. This is not working anymore of course.
@Jesse:
With the zentimestamp plugin beeing fixed, there is no need to have a BUILD_TIMESTAMP_LEGACY variable. The purpose of this plugin is to:
change the Jenkins build timestamp format (provided by the Jenkins BUILD_ID variable)
So if people need another formatting than the default one, this plugin provides the mechanism to change it.
Adding milliseconds to the new timestamp variable may not be necessary.
The BUILD_ID is the better choice for getting a unique identifier.
I also used the BUILD_ID to tag artifacts with a date.
To me BUILD_ID is fine as the BUILD_NUMBER.
I do still need a global variable with the date, and BUILD_TIMESTAMP seems like the best way to do this, as long as it is the start date and time of the job in the local timezone.
Can this be added and the documentation updated? As others have said, the documentation still shows that BUILD_ID is giving this date.
mre_mchp agreed, that plugin seems like the right place to host this kind of functionality.
And yes, it is a core bug if the documentation still suggests that BUILD_ID is a date.
Is there a workaround for the git-publisher? We use to tag our nightly Versions, though I need a date in the git-publisher
I added a note to the documentation. Should be accomodated as soon as this issue is resolved.
I was using BUILD_ID for the timestamp.
It is still documented as: "2005-08-22_23-59-59" (YYYY-MM-DD_hh-mm-ss, defunct since version 1.597)
I do not understand why someone would change this without providing an alternative.
Breaking someone's code with no compelling reason seems, well just wrong.
I want to be able to log the time of the build. In my case with p4 rebuilding the workspace,
that is sometimes the longest part of the build. There is no way to get this information
because by the time my scripts starts, 15 minutes has already passed.
Best would be to change it back to the way it was. OK would be to provide a new environment variable.
Preferably with the same format. In the mean time, I'm going back to an older version.
I do not understand why someone would change this without providing an alternative.
You're using BUILD_ID for something other than identifying builds, which it is meant for. So sure, it was documented as being a time stamp, but it's not unencumbered with other uses.
Breaking someone's code with no compelling reason seems, well just wrong.
The previous BUILD_ID format required tons of additional code and had several limitations, which have all been fixed by switching to build numbers. Looks like a compelling reason to me.
Best would be to change it back to the way it was. OK would be to provide a new environment variable. Preferably with the same format.
Neither going back to the old storage format, nor using a value for BUILD_ID which isn't actually the build ID, are sane options going forward IMO. A new variable should be easy to add, if maybe only in a plugin.
I create BUILD_TIMESTAMP variable defined as below to resolve this issue.
BUILD_TIMESTAMP=`date +'%Y-%m-%d_%H-%M-%S'`
@Peter Hackett: There was good reasons to use a different BUILD_ID than the timestamp. Using BUILD_TIMESTAMP instead should be a feasible change for everybody, not?
There is an alternative solution available. Please read my first comment above. This Groovy-one-liner will define a BUILD_TIMESTAMP variable.
The timestamp of this variable will match the exact time when Jenkins triggered the build (the time that will be shown in the build history of each job).
There is no jitter like its possible if you use the current time by calling e.g. 'date' from inside your build scripts.
Once this ticket is fixed, this workaround can be removed seamlessly.
The proposed workarounds do not take into account the loss of a variable with the value of the old BUILD_ID.
If you want to determine the file location of an archive, you need the old definition of BUILD_NUMBER (which matched BUILD_DISPLAY_NAME minus the "#") and BUILD_ID.
$JENKINS_HOME/jobs/$JOB_NAME/builds/$OLD_BUILD_NUMBER/archive/file-name-$BUILD_NUMBER.tar.gz
In a shell, I can use this instead:
export BUILD_DISPLAY_NUMBER=$(echo "${BUILD_DISPLAY_NAME}" | awk -F"#" '
')
But it isn't used by downstream builds.
To add a variable usable as a environment variable, you can use the Prepare an environment for the run section. This requires groovy installed on your system.
Add an evaluated Groovy script with the following... (or if you already have a groovy script here, incorporate this code)
import java.text.SimpleDateFormat
def map = [ "BUILD_TIMESTAMP":new SimpleDateFormat("yyyy-MM-dd_kk-mm-ss").format(new Date()) ]
return map
Prepare an environment for the run section. This requires groovy installed on your system
Requires no Groovy to be installed, just the env-inject Jenkins plugin.
Jesse, What are your plans in respect of this issue?
I've applied the Groovy script workaround to inject BUILD_TIMESTAMP into my builds and have adjusted usage of BUILD_ID to match. That all works fine.
If that is going to be the recommended way to fixup affected systems then personally I am fine with that and I would suggest that this issue will be closed as will not fix with the workaround documented.
If the intention is to add a BUILD_TIMESTAMP variable parallel to BUILD_ID then I will adapt my earlier fix if you do not have the bandwidth to do that.
I think this should be handled in the Zentimestamp plugin, not core. I will file a PR for the documentation, which I see got overlooked.
i'm very disapointed to see this new message ! won't fix ...
This is was very usefull feature which is now removed. We stop upgrading Jenkins since this change and now we see that it will not be fixed.
Assuming the maintainer of the Zentimestamp plugin is responsive (I do not follow it), this should be simple to implement there, and provide more flexibility anyway. (The old BUILD_ID lacked millisecond resolution, whereas Jenkins now supports >1 build of a given project per second, making timestamps in that format nonunique; and also used the server’s current timezone, leading to subtle problems during DST changes or when simply moving servers.)
Code changed in jenkins
User: Jesse Glick
Path:
core/src/main/resources/jenkins/model/CoreEnvironmentContributor/buildEnv.properties
http://jenkins-ci.org/commit/jenkins/77327a5e37a10244f4ad2bc23988b96982caf200
Log:
JENKINS-26520 Documentation for $BUILD_ID did not reflect current reality.
Code changed in jenkins
User: Jesse Glick
Path:
core/src/main/resources/jenkins/model/CoreEnvironmentContributor/buildEnv.properties
http://jenkins-ci.org/commit/jenkins/e80c69c433a4b90e18af234c154eec44803cafd1
Log:
Merge pull request #1637 from jglick/BUILD_ID-JENKINS-26520
JENKINS-26520 Documentation fix for $BUILD_ID
Compare: https://github.com/jenkinsci/jenkins/compare/c2e9423b95cb...e80c69c433a4
fpoulet and others, PR 1 in the Zentimestamp plugin now uses BUILD_TIMESTAMP as an environment variable instead of the BUILD_ID.
Code changed in jenkins
User: Stephen Connolly
Path:
changelog.html
http://jenkins-ci.org/commit/jenkins/9fd4c1a854dfea43501060511cfd3597d83a0226
Log:
[FIXED JENKINS-26520] Noting merge of #1637
Integrated in jenkins_main_trunk #4075
[FIXED JENKINS-26520] Noting merge of #1637 (Revision 9fd4c1a854dfea43501060511cfd3597d83a0226)
Result = SUCCESS
stephen connolly : 9fd4c1a854dfea43501060511cfd3597d83a0226
Files :
- changelog.html
This is very unfortunate. I used the Build_id and build_number as a way to tie the build to the distribution folder. It was easy for people to find the build. If this was 'not fixed' a while ago then the documentation should have gone in already. I was trying to move over to Jenkins from Hudson but now I see it will be a lot more work than I was prepared to do.
cojeff Read my comment from above. You can use the Zentimestamp plugin which will expose BUILD_TIMESTAMP environment variable.
If BUILD_TIMESTAMP is a Jenkins variable, why can't it be used directly (without using the Zentimestamp plugin).
If BUILD_TIMESTAMP is a Jenkins variable, why can't it be used directly (without using the Zentimestamp plugin).
That variable is not provided by Jenkins core. It's not defined without Zentimestamp.
Jenkins core changed the storage format and therefore the format of the BUILD_ID variable contents. If you were using it for something other than a reference to the build folder name (e.g. to indicate start date and time of a build), you now need to switch to using BUILD_TIMESTAMP provided by Zentimestamp, or determine the date on your own (some solutions provided in comments above).
The recent change in core was a documentation fix.
I have installed zentimestamp-plugin and trying to get build execution time in email notifications.
I used Zentimestamp plugin and using env variable BUILD_TIMESTAMP using following ways but not able to get actual time stamp value
${BUILD_TIMESTAMP} $BUILD_TIMESTAMP BUILD_TIMESTAMP
Somebody Please answer here ? http://stackoverflow.com/questions/29580315/jenkins-how-to-use-zentimestamp-plugin-to-get-build-execution-time
Did you select 'Change date pattern for the BUILD_TIMESTAMP (build timestamp) variable' and supply a 'Date and Time Pattern'.
I believe if you do not select that option, the variable does not get expanded.
I set a value for 'Date and Time pattern as 'yyyy-MM-dd_HH-mm-ss' and it worked fine.
That's right. The actual behavior of the Zen-Timestamp plugin is to modify the environment variable only if "Change date pattern" was checked. With older Jenkins versions, the variable BUILD_ID was
already set to the default format by the Jenkins core and was only modified by the plugin if this option was checked and a different format was selected. The new Zen plugin must be fixed to set the BUILD_TIMESTAMP variable in any case, even if there was no format defined inside the job or node configuration. I will file a ticket for this issue.
Thanks @michael and @Malcom,
Yes, it works fine after specifying proper time pattern.
It would be great help if author add litle description here in wiki ? as like other plugins.
I tried a test with one of my jobs and the zen-timestamp plugin.
I had the line "Changing BUILD_ID variable (job build time) with the date pattern yyyy-MM-dd_HH-mm-ss." in my log 10+ times.
You also have to specify this option in EVERY individual build? How is this at all an acceptable replacement?
Why can we not make BUILD_TIMESTAMP a Jenkins default variable?
You can specify the format in the Manage Jenkins > Configure System > Global Properties then just pass the Build_Timestamp variable to your Build_ID variable you were using in your scripts. I was able to get this to work exactly without too much code changes. If some other project wants to use a different time stamp format then you will have that ability to change it at the project level.
@Chris
There is still a bug inside the ZenTimestamp Plugin. Once this is fixed, you do not have to check this option in every Jenkins job configuration.
It should be enough to install the ZenTimestamp plugin. Then the BUILD_TIMESTAMP variable will be set to its default format.
So far, until this issue inside the ZenTimestamp plugin was fixed, you have to set it in every job config (like you noticed).
Or, as a simple workaround, set the ZenTimestamp format on the global Jenkins configuration page. That option should apply for all jobs then. (Jeff was faster here
Once the plugin was fixed, even this check box is not necessary anymore. See the last comments on the reopened issue JENKINS-26626
I think BUILD_ID should keep the timestamp format. That is the documented behaviour at
https://wiki.jenkins-ci.org/display/JENKINS/Building+a+software+project
The BUILD_NUMBER variable gives the build number still.
The change of format has broken a couple of my deployment scripts that were expecting the date format.
I did a quick fix to use the old formatting code and that seems to have made things work for me. I have not submitted a pull request because I have not had chance to fully test things. For those who are interested the code is at
https://github.com/oldelvet/jenkins/tree/jenkins-26520