• Icon: Bug Bug
    • Resolution: Duplicate
    • Icon: Major Major
    • core
    • Windows 7 64Bit, jenkins 1.600

      Since the update to jenkins 1.600 every project has the BUILDID and BUILD_TAG from previous project:

      BUILD_DISPLAY_NAME=#1964
      BUILD_ID=442
      BUILD_NUMBER=442
      BUILD_TAG=jenkins-ImageVision_1-442
      BUILD_URL=http://heilbutt:8080/job/DiaShow_Easy/1964/

      While I'm not happy that for some time now the BUILD_ID has been the same number as the BUILD_DISPLAY_NAME instead of a timestamp, this new discrepancy needs to be fixed quickly.

          [JENKINS-27188] BUILDID and BUILD_TAG from previous project

          Daniel Beck added a comment -

          Are you using env-inject? If so, this may be related to JENKINS-27178.

          Daniel Beck added a comment - Are you using env-inject? If so, this may be related to JENKINS-27178 .

          No, I don't use env-inject, and luckily so far I didn't run into any other errors.
          But I will switch back to 1.599 as well.

          Kerstin Thaler added a comment - No, I don't use env-inject, and luckily so far I didn't run into any other errors. But I will switch back to 1.599 as well.

          Daniel Beck added a comment -

          FWIW my branch of 1.600 with the fix for JENKINS-27178 (see comments there) prevents this issue from occurring on my test instance as well.

          Daniel Beck added a comment - FWIW my branch of 1.600 with the fix for JENKINS-27178 (see comments there) prevents this issue from occurring on my test instance as well.

          Daniel Beck added a comment - - edited

          I can only reproduce this problem on 1.600 with env-inject installed and enabled. Without it, this issue doesn't occur. Could you double-check whether the plugin is installed and enabled? It doesn't have to be used in any jobs or nodes.

          Daniel Beck added a comment - - edited I can only reproduce this problem on 1.600 with env-inject installed and enabled. Without it, this issue doesn't occur. Could you double-check whether the plugin is installed and enabled? It doesn't have to be used in any jobs or nodes.

          Daniel Beck added a comment -

          Someone mentioned on #jenkins that they experience the wrong WORKSPACE being set for their jobs.

          [2015-03-02 10:31:40] <Johnou_> has anyone else experienced WORKSPACE job variable pointing to the incorrect job dir?

          That may be this issue as well.

          Daniel Beck added a comment - Someone mentioned on #jenkins that they experience the wrong WORKSPACE being set for their jobs. [2015-03-02 10:31:40] <Johnou_> has anyone else experienced WORKSPACE job variable pointing to the incorrect job dir? That may be this issue as well.

          Yes, I do have env-inject installed and enabled.

          Kerstin Thaler added a comment - Yes, I do have env-inject installed and enabled.

          Daniel Beck added a comment -

          Alright, we see the same issue then.

          Also,

          [2015-03-02 11:14:58] <Johnou_> BUILD_TAG is incorrect as well
          [2015-03-02 11:15:13] <Johnou_> i did trawl through jira but I was looking for WORKSPACE
          [2015-03-02 11:15:32] <Johnou_> yes we use the envinject plugin

          Daniel Beck added a comment - Alright, we see the same issue then. Also, [2015-03-02 11:14:58] <Johnou_> BUILD_TAG is incorrect as well [2015-03-02 11:15:13] <Johnou_> i did trawl through jira but I was looking for WORKSPACE [2015-03-02 11:15:32] <Johnou_> yes we use the envinject plugin

          Just for the sake of completeness, the variable JOB_NAME is the one of the previous project too.

          Currently we don't run parallel builds and all build are started manually, but so that each one is already waiting for one to finish, i.e. in a queue.

          Kerstin Thaler added a comment - Just for the sake of completeness, the variable JOB_NAME is the one of the previous project too. Currently we don't run parallel builds and all build are started manually, but so that each one is already waiting for one to finish, i.e. in a queue.

          Same problem here: after update to 1.600 environment variables from different builds started to show up. They could be seen on the system information of each node.
          Among others: WORKSPACE, GIT_COMMIT_HASH, JOB_NAME,...
          Tried to:

          • remove EnvInject -> same issue.
          • restart agents on nodes -> same issue
          • switch back to 1.599 (still no EnvInject) -> everything fine again.

          Emmanuel Guérin added a comment - Same problem here: after update to 1.600 environment variables from different builds started to show up. They could be seen on the system information of each node. Among others: WORKSPACE, GIT_COMMIT_HASH, JOB_NAME,... Tried to: remove EnvInject -> same issue. restart agents on nodes -> same issue switch back to 1.599 (still no EnvInject) -> everything fine again.

          Daniel Beck added a comment -

          eguerints: To clarify, just removing env-inject (and restarting Jenkins) was not sufficient? You see this issue without env-inject installed at all?

          Daniel Beck added a comment - eguerints : To clarify, just removing env-inject (and restarting Jenkins) was not sufficient? You see this issue without env-inject installed at all?

          Yes, when I removed the plugin on 1.600 and restarted the master and the slaves, I still had the issue.
          Unfortunately, I didn't have enough time to investigate further. What puzzled me seemed that the environment variables seemed to be impervious to restarts.
          So there may be other factors that I couldn't see.
          But switching back to 1.599 did solve the problem, and I didn't have to restart the nodes for their system information pages to be correct and the builds to work normally.
          Sorry for the lack of détails.

          Emmanuel Guérin added a comment - Yes, when I removed the plugin on 1.600 and restarted the master and the slaves, I still had the issue. Unfortunately, I didn't have enough time to investigate further. What puzzled me seemed that the environment variables seemed to be impervious to restarts. So there may be other factors that I couldn't see. But switching back to 1.599 did solve the problem, and I didn't have to restart the nodes for their system information pages to be correct and the builds to work normally. Sorry for the lack of détails.

          Same here. We're using vars like ${env.BUILD_NUMBER} in ANT Buildscripts to tag builds in vcs. Since we upgraded to 1.600 these vars are filled with the information from the last build in the whole Jenkins instance (job independent).

          Adrian Kirchner added a comment - Same here. We're using vars like ${env.BUILD_NUMBER} in ANT Buildscripts to tag builds in vcs. Since we upgraded to 1.600 these vars are filled with the information from the last build in the whole Jenkins instance (job independent).

          John McClane added a comment -

          We are using the Build Flow plugin and the build numbers are not being passed correctly after upgrading to 1.600.

          build_job1 = build("Build 1")
          build_job2 = build("Build 2")
          deploy_job = build("Deploy", DEPLOY_BUILD_NUMBER: build_job2.build.number)

          When the "Deploy" job runs in this instance, the DEPLOY_BUILD_NUMBER environment variable is the one from build_job1 instead of build_job2. I realize this thread is not about the Build Flow Plugin but I'm guessing the root cause is the same.

          John McClane added a comment - We are using the Build Flow plugin and the build numbers are not being passed correctly after upgrading to 1.600. build_job1 = build("Build 1") build_job2 = build("Build 2") deploy_job = build("Deploy", DEPLOY_BUILD_NUMBER: build_job2.build.number) When the "Deploy" job runs in this instance, the DEPLOY_BUILD_NUMBER environment variable is the one from build_job1 instead of build_job2. I realize this thread is not about the Build Flow Plugin but I'm guessing the root cause is the same.

          Code changed in jenkins
          User: Jesse Glick
          Path:
          test/src/test/java/hudson/model/NodeTest.java
          test/src/test/java/jenkins/tasks/SimpleBuildWrapperTest.java
          http://jenkins-ci.org/commit/jenkins/e559f39697dad8ee44320b092fc7b32c35ac1eb9
          Log:
          JENKINS-27188 Picking a better test location for #1590.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: test/src/test/java/hudson/model/NodeTest.java test/src/test/java/jenkins/tasks/SimpleBuildWrapperTest.java http://jenkins-ci.org/commit/jenkins/e559f39697dad8ee44320b092fc7b32c35ac1eb9 Log: JENKINS-27188 Picking a better test location for #1590.

          Code changed in jenkins
          User: Jesse Glick
          Path:
          changelog.html
          http://jenkins-ci.org/commit/jenkins/7d6cd1bd5b4675dbbcf1df08eb4760fdaea8dffc
          Log:
          JENKINS-27188 Noting merge of #1590.

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Jesse Glick Path: changelog.html http://jenkins-ci.org/commit/jenkins/7d6cd1bd5b4675dbbcf1df08eb4760fdaea8dffc Log: JENKINS-27188 Noting merge of #1590.

          dogfood added a comment -

          Integrated in jenkins_main_trunk #3994
          JENKINS-27188 Picking a better test location for #1590. (Revision e559f39697dad8ee44320b092fc7b32c35ac1eb9)
          JENKINS-27188 Noting merge of #1590. (Revision 7d6cd1bd5b4675dbbcf1df08eb4760fdaea8dffc)

          Result = SUCCESS
          jesse glick : e559f39697dad8ee44320b092fc7b32c35ac1eb9
          Files :

          • test/src/test/java/hudson/model/NodeTest.java
          • test/src/test/java/jenkins/tasks/SimpleBuildWrapperTest.java

          jesse glick : 7d6cd1bd5b4675dbbcf1df08eb4760fdaea8dffc
          Files :

          • changelog.html

          dogfood added a comment - Integrated in jenkins_main_trunk #3994 JENKINS-27188 Picking a better test location for #1590. (Revision e559f39697dad8ee44320b092fc7b32c35ac1eb9) JENKINS-27188 Noting merge of #1590. (Revision 7d6cd1bd5b4675dbbcf1df08eb4760fdaea8dffc) Result = SUCCESS jesse glick : e559f39697dad8ee44320b092fc7b32c35ac1eb9 Files : test/src/test/java/hudson/model/NodeTest.java test/src/test/java/jenkins/tasks/SimpleBuildWrapperTest.java jesse glick : 7d6cd1bd5b4675dbbcf1df08eb4760fdaea8dffc Files : changelog.html

          Daniel Beck added a comment -

          The cause and fix for this is the same as for JENKINS-27178. This will be fixed in 1.601 (despite what the changelog on the Jenkins website might say).

          Daniel Beck added a comment - The cause and fix for this is the same as for JENKINS-27178 . This will be fixed in 1.601 (despite what the changelog on the Jenkins website might say).

          Daniel Beck added a comment -

          A user reported this issue affecting Jenkins 1.602. Does anyone watching this issue know anything about that?

          Daniel Beck added a comment - A user reported this issue affecting Jenkins 1.602. Does anyone watching this issue know anything about that?

          I also experienced this (or related) issue with 1.602. PATH variable is being messed up from different jobs and/or nodes. Using EnvInject 1.91.1, downgraded to 1.90 didn't fix the issue. Reverting core to 1.598 fixes behavior immediately.

          Krzysztof Malinowski added a comment - I also experienced this (or related) issue with 1.602. PATH variable is being messed up from different jobs and/or nodes. Using EnvInject 1.91.1, downgraded to 1.90 didn't fix the issue. Reverting core to 1.598 fixes behavior immediately.

          Daniel Beck added a comment -

          raspy Please file a new issue and provide as much detail has you can. https://wiki.jenkins-ci.org/display/JENKINS/How+to+report+an+issue

          Daniel Beck added a comment - raspy Please file a new issue and provide as much detail has you can. https://wiki.jenkins-ci.org/display/JENKINS/How+to+report+an+issue

          Actually it's rather JENKINS-27197 which was duplicated to this issue. Moreover, you asked if it is still visible, so I reported. If you prefer another issue for this behavior, I can raise a new one.

          Krzysztof Malinowski added a comment - Actually it's rather JENKINS-27197 which was duplicated to this issue. Moreover, you asked if it is still visible, so I reported. If you prefer another issue for this behavior, I can raise a new one.

          Daniel Beck added a comment -

          If you prefer another issue for this behavior, I can raise a new one.

          Yes please. Unless the environment variables mentioned in the original report are still broken for you, it's a different (but possibly related) issue.

          Daniel Beck added a comment - If you prefer another issue for this behavior, I can raise a new one. Yes please. Unless the environment variables mentioned in the original report are still broken for you, it's a different (but possibly related) issue.

            ndeloof Nicolas De Loof
            pfennig59 Kerstin Thaler
            Votes:
            4 Vote for this issue
            Watchers:
            15 Start watching this issue

              Created:
              Updated:
              Resolved: