Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-26520

Environment Variables BUILD_ID and BUILD_NUMBER now return the same value

    • Icon: Bug Bug
    • Resolution: Won't Fix
    • Icon: Minor Minor
    • core
    • None
    • Since version 1.597

      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

          [JENKINS-26520] Environment Variables BUILD_ID and BUILD_NUMBER now return the same value

          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

          Richard Mortimer added a comment - 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

          Jesse Glick added a comment -

          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.

          Jesse Glick added a comment - 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.

          Michael Rentschler added a comment - 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.

          Michael Rentschler added a comment - - edited

          @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.

          Michael Rentschler added a comment - - edited @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.

          Chris Tobey added a comment - - edited

          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.

          Chris Tobey added a comment - - edited 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.

          Jesse Glick added a comment -

          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.

          Jesse Glick added a comment - 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

          Till Steinbach added a comment - Is there a workaround for the git-publisher? We use to tag our nightly Versions, though I need a date in the git-publisher

          Martin Rust added a comment -

          I added a note to the documentation. Should be accomodated as soon as this issue is resolved.

          Martin Rust added a comment - I added a note to the documentation. Should be accomodated as soon as this issue is resolved.

          sogabe added a comment -

          What's the status now?

          sogabe added a comment - What's the status now?

          Bo-Yi Wu added a comment -

          Any updates?

          Bo-Yi Wu added a comment - Any updates?

          Peter Hackett added a comment -

          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.

          Peter Hackett added a comment - 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.

          Daniel Beck added a comment -

          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.

          Daniel Beck added a comment - 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.

          Bo-Yi Wu added a comment -

          I create BUILD_TIMESTAMP variable defined as below to resolve this issue.

          BUILD_TIMESTAMP=`date +'%Y-%m-%d_%H-%M-%S'`

          Bo-Yi Wu added a comment - 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.

          Michael Rentschler added a comment - @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.

          Drew Gulino added a comment -

          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"#" '

          {print $2}

          ')
          But it isn't used by downstream builds.

          Drew Gulino added a comment - 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"#" ' {print $2} ') But it isn't used by downstream builds.

          Tom Moore added a comment -

          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

          Tom Moore added a comment - 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

          Daniel Beck added a comment -

          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.

          Daniel Beck added a comment - 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.

          Richard Mortimer added a comment - 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.

          Jesse Glick added a comment -

          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.

          Jesse Glick added a comment - 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.

          Poulet Fabrice added a comment - 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.

          Jesse Glick added a comment -

          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.)

          Jesse Glick added a comment - 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.)

          Thank, the reason is more clear and we can undestand this.

          Poulet Fabrice added a comment - Thank, the reason is more clear and we can undestand this.

          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.

          SCM/JIRA link daemon added a comment - 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

          SCM/JIRA link daemon added a comment - 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.

          Steven Christou added a comment - 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

          SCM/JIRA link daemon added a comment - 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

          dogfood added a comment -

          Integrated in jenkins_main_trunk #4074

          Result = SUCCESS

          dogfood added a comment - Integrated in jenkins_main_trunk #4074 Result = SUCCESS

          dogfood added a comment -

          Integrated in jenkins_main_trunk #4075
          [FIXED JENKINS-26520] Noting merge of #1637 (Revision 9fd4c1a854dfea43501060511cfd3597d83a0226)

          Result = SUCCESS
          stephen connolly : 9fd4c1a854dfea43501060511cfd3597d83a0226
          Files :

          • changelog.html

          dogfood added a comment - Integrated in jenkins_main_trunk #4075 [FIXED JENKINS-26520] Noting merge of #1637 (Revision 9fd4c1a854dfea43501060511cfd3597d83a0226) Result = SUCCESS stephen connolly : 9fd4c1a854dfea43501060511cfd3597d83a0226 Files : changelog.html

          Jeff Foege added a comment -

          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.

          Jeff Foege added a comment - 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.

          Steven Christou added a comment - 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).

          Malcolm Fernandes added a comment - If BUILD_TIMESTAMP is a Jenkins variable, why can't it be used directly (without using the Zentimestamp plugin).

          Daniel Beck added a comment -

          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.

          Daniel Beck added a comment - 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

          Swapnil Kotwal added a comment - 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.

          Malcolm Fernandes added a comment - 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.

          Michael Rentschler added a comment - 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.

          Swapnil Kotwal added a comment - 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.

          Chris Tobey added a comment - - edited

          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?

          Chris Tobey added a comment - - edited 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?

          Jeff Foege added a comment -

          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.

          Jeff Foege added a comment - 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.

          Michael Rentschler added a comment - - edited

          @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

          Michael Rentschler added a comment - - edited @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

            jglick Jesse Glick
            applican David Sommer
            Votes:
            20 Vote for this issue
            Watchers:
            33 Start watching this issue

              Created:
              Updated:
              Resolved: