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

Environment Variables BUILD_ID and BUILD_NUMBER now return the same value

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Minor
    • Resolution: Won't Fix
    • Component/s: core
    • Labels:
      None
    • Environment:
      Since version 1.597
    • Similar Issues:

      Description

      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

        Attachments

          Issue Links

            Activity

            Hide
            oldelvet 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

            Show
            oldelvet 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
            Hide
            jglick 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.

            Show
            jglick 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.
            Hide
            mre_mchp 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.

            Show
            mre_mchp 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.
            Hide
            mre_mchp 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.

            Show
            mre_mchp 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.
            Hide
            tobeychris 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.

            Show
            tobeychris 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.
            Hide
            jglick Jesse Glick added a comment -

            Michael Rentschler 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.

            Show
            jglick Jesse Glick added a comment - Michael Rentschler 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.
            Hide
            steinbach 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

            Show
            steinbach 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
            Hide
            martin_rust Martin Rust added a comment -

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

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

            What's the status now?

            Show
            sogabe sogabe added a comment - What's the status now?
            Hide
            appleboy Bo-Yi Wu added a comment -

            Any updates?

            Show
            appleboy Bo-Yi Wu added a comment - Any updates?
            Hide
            pdhackett 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.

            Show
            pdhackett 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.
            Hide
            danielbeck 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.

            Show
            danielbeck 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.
            Hide
            appleboy 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'`

            Show
            appleboy 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'`
            Hide
            mre_mchp 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.

            Show
            mre_mchp 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.
            Hide
            dgulino 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.

            Show
            dgulino 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.
            Hide
            tmoore 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

            Show
            tmoore 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
            Hide
            danielbeck 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.

            Show
            danielbeck 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.
            Hide
            oldelvet 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.

            Show
            oldelvet 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.
            Hide
            jglick 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.

            Show
            jglick 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.
            Hide
            fpoulet 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.

            Show
            fpoulet 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.
            Hide
            jglick 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.)

            Show
            jglick 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.)
            Hide
            fpoulet Poulet Fabrice added a comment -

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

            Show
            fpoulet Poulet Fabrice added a comment - Thank, the reason is more clear and we can undestand this.
            Hide
            scm_issue_link 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.

            Show
            scm_issue_link 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.
            Hide
            scm_issue_link 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

            Show
            scm_issue_link 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
            Hide
            schristou Steven Christou added a comment -

            Poulet Fabrice and others, PR 1 in the Zentimestamp plugin now uses BUILD_TIMESTAMP as an environment variable instead of the BUILD_ID.

            Show
            schristou Steven Christou added a comment - Poulet Fabrice and others, PR 1 in the Zentimestamp plugin now uses BUILD_TIMESTAMP as an environment variable instead of the BUILD_ID.
            Hide
            scm_issue_link 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

            Show
            scm_issue_link 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
            Hide
            dogfood dogfood added a comment -

            Integrated in jenkins_main_trunk #4074

            Result = SUCCESS

            Show
            dogfood dogfood added a comment - Integrated in jenkins_main_trunk #4074 Result = SUCCESS
            Hide
            dogfood 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
            Show
            dogfood 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
            Hide
            cojeff 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.

            Show
            cojeff 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.
            Hide
            schristou Steven Christou added a comment -

            Jeff Foege Read my comment from above. You can use the Zentimestamp plugin which will expose BUILD_TIMESTAMP environment variable.

            Show
            schristou Steven Christou added a comment - Jeff Foege Read my comment from above. You can use the Zentimestamp plugin which will expose BUILD_TIMESTAMP environment variable.
            Hide
            malferns Malcolm Fernandes added a comment -

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

            Show
            malferns Malcolm Fernandes added a comment - If BUILD_TIMESTAMP is a Jenkins variable, why can't it be used directly (without using the Zentimestamp plugin).
            Hide
            danielbeck 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.

            Show
            danielbeck 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.
            Hide
            swapnilvkotwal 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

            Show
            swapnilvkotwal 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
            Hide
            malferns 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.

            Show
            malferns 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.
            Hide
            mre_mchp 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.

            Show
            mre_mchp 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.
            Hide
            swapnilvkotwal 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.

            Show
            swapnilvkotwal 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.
            Hide
            tobeychris 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?

            Show
            tobeychris 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?
            Hide
            cojeff 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.

            Show
            cojeff 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.
            Hide
            mre_mchp 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

            Show
            mre_mchp 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

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved: