[JENKINS-32218] buildsByBranchName is not set anymore

Type: Bug
Resolution: Fixed
Priority: Major
Component/s: git-plugin
Labels:
None
Environment:
git-plugin 2.4.1
Jenkins 1.643

Similar Issues:
Powered by SuggestiMate

Show

I noticed that GIT_PREVIOUS_SUCCESSFUL_COMMIT was not set anymore on the Job that only builds our master branch. After some digging I found out that since the upgrade from the previous version (I can't find which version that was, is that stored somewhere?) the buildsByBranchName variable in any `build.xml` is not set anymore (it's empty). It is set in other jobs we have, just not this one.

This env is critical for us, so I'm going to try to rollback. I'm glad to help track down this problem if possible.

is related to

JENKINS-19022 GIT Plugin (any version) heavily bloats memory use and size of build.xml with "BuildData" fields

Open

JENKINS-29482 Prune stale branches prevents git plugin change history display

Closed

Alex Nederlof created issue - 2015-12-29 15:03

Alex Nederlof added a comment - 2015-12-29 15:27 - edited

Looking at the diff and the version timestamps I'm almost certain we ran 2.4.0 before this version, so it is a regression to 2.4.1

Alex Nederlof added a comment - 2015-12-29 15:27 - edited Looking at the diff and the version timestamps I'm almost certain we ran 2.4.0 before this version, so it is a regression to 2.4.1

Mark Waite made changes - 2015-12-30 01:08

Description

Original: I noticed that GIT_PREVIOUS_SUCCESSFUL_COMMIT was not set anymore on the Job that only builds our master branch. After some digging I found out that since the upgrade from the previous version (I can't find which version that was, is that stored somewhere?) the buildsByBranchName variable in any `build.xml` is not set anymore (it's empty). It is set in other jobs we have, just not this one.

This env is critical for us, so I'm going to try to rollback. I'm glad to help track down this problem if possible.

New: _emphasized text_I noticed that GIT_PREVIOUS_SUCCESSFUL_COMMIT was not set anymore on the Job that only builds our master branch. After some digging I found out that since the upgrade from the previous version (I can't find which version that was, is that stored somewhere?) the buildsByBranchName variable in any `build.xml` is not set anymore (it's empty). It is set in other jobs we have, just not this one.

This env is critical for us, so I'm going to try to rollback. I'm glad to help track down this problem if possible.

Mark Waite made changes - 2015-12-30 01:25

Description

Original: _emphasized text_I noticed that GIT_PREVIOUS_SUCCESSFUL_COMMIT was not set anymore on the Job that only builds our master branch. After some digging I found out that since the upgrade from the previous version (I can't find which version that was, is that stored somewhere?) the buildsByBranchName variable in any `build.xml` is not set anymore (it's empty). It is set in other jobs we have, just not this one.

This env is critical for us, so I'm going to try to rollback. I'm glad to help track down this problem if possible.

New: I noticed that GIT_PREVIOUS_SUCCESSFUL_COMMIT was not set anymore on the Job that only builds our master branch. After some digging I found out that since the upgrade from the previous version (I can't find which version that was, is that stored somewhere?) the buildsByBranchName variable in any `build.xml` is not set anymore (it's empty). It is set in other jobs we have, just not this one.

This env is critical for us, so I'm going to try to rollback. I'm glad to help track down this problem if possible.

Mark Waite added a comment - 2015-12-30 01:33 - edited

Can you explain the relationship between buildsByBranchName in your build.xml file and GIT_PREVIOUS_SUCCESSFUL_COMMIT?

When you say that GIT_PREVIOUS_SUCCESSFUL_COMMIT is not set anymore on the job that builds your master branch, I assume that means in git plugin 2.4.0 it was set on builds of that job, but now with git plugin 2.4.1 it is no longer set. Have I interpreted that part correctly?

Can you also further explain your comment that this behavior seems to be specific to a single job? I assume that means you are using GIT_PREVIOUS_SUCCESSFUL_COMMIT in other jobs, and it is still working in those other jobs. Can you identify key differences between the jobs where it is working and the jobs where it is not working?

The code which computes GIT_PREVIOUS_SUCCESSFUL_COMMIT uses "getBuildData()". That general area of the plugin which modified in the 2.4.1 change window by a change from Nicolas de Loof and by one or more changes from Andrew Bayer. It has been an especially challenging portion of the plugin.

The "Manage plugins" section of the Jenkins configuration pages includes a page which allows you to revert to the prior plugin version. If you have not already reverted, that will show you the version of the plugin you were previously running.

Mark Waite added a comment - 2015-12-30 01:33 - edited Can you explain the relationship between buildsByBranchName in your build.xml file and GIT_PREVIOUS_SUCCESSFUL_COMMIT? When you say that GIT_PREVIOUS_SUCCESSFUL_COMMIT is not set anymore on the job that builds your master branch, I assume that means in git plugin 2.4.0 it was set on builds of that job, but now with git plugin 2.4.1 it is no longer set. Have I interpreted that part correctly? Can you also further explain your comment that this behavior seems to be specific to a single job? I assume that means you are using GIT_PREVIOUS_SUCCESSFUL_COMMIT in other jobs, and it is still working in those other jobs. Can you identify key differences between the jobs where it is working and the jobs where it is not working? The code which computes GIT_PREVIOUS_SUCCESSFUL_COMMIT uses "getBuildData()". That general area of the plugin which modified in the 2.4.1 change window by a change from Nicolas de Loof and by one or more changes from Andrew Bayer. It has been an especially challenging portion of the plugin. The "Manage plugins" section of the Jenkins configuration pages includes a page which allows you to revert to the prior plugin version. If you have not already reverted, that will show you the version of the plugin you were previously running.

Alex Nederlof added a comment - 2015-12-30 10:54

I noticed the GIT_PREVIOUS_SUCCESSFUL_COMMIT was empty since the upgrade. I looked through the code and found this piece of code where it is set. That gave me the idea to check the build.xml files for changes, and sure enough, the place where it gets the branch information from (buildsByBranchName ) was empty.

When you say that GIT_PREVIOUS_SUCCESSFUL_COMMIT is not set anymore on the job that builds your master branch, I assume that means in git plugin 2.4.0 it was set on builds of that job, but now with git plugin 2.4.1 it is no longer set. Have I interpreted that part correctly?

Correct. It was set in 2.4.0. It is not set in 2.4.1. After rolling back to 2.4.0 it is set again. Same goes for buildsByBranchName in the build.xml.

Can you identify key differences between the jobs where it is working and the jobs where it is not working?

The only difference really is the branch it builds. One builds master (branch specifier */master), and has some post actions the other doesn't have. The other job builds everything but master by using the same branch specifier but with the "inverse strategy".

Thanks for you help!

Alex Nederlof added a comment - 2015-12-30 10:54 I noticed the GIT_PREVIOUS_SUCCESSFUL_COMMIT was empty since the upgrade. I looked through the code and found this piece of code where it is set . That gave me the idea to check the build.xml files for changes, and sure enough, the place where it gets the branch information from (buildsByBranchName ) was empty. When you say that GIT_PREVIOUS_SUCCESSFUL_COMMIT is not set anymore on the job that builds your master branch, I assume that means in git plugin 2.4.0 it was set on builds of that job, but now with git plugin 2.4.1 it is no longer set. Have I interpreted that part correctly? Correct. It was set in 2.4.0. It is not set in 2.4.1. After rolling back to 2.4.0 it is set again. Same goes for buildsByBranchName in the build.xml. Can you identify key differences between the jobs where it is working and the jobs where it is not working? The only difference really is the branch it builds. One builds master (branch specifier */master ), and has some post actions the other doesn't have. The other job builds everything but master by using the same branch specifier but with the "inverse strategy". Thanks for you help!

Alex Nederlof added a comment - 2015-12-30 11:04 - edited

In case it helps, here's the 2.4.0 output:

<hudson.plugins.git.util.BuildData plugin="git@2.4.0">
      <buildsByBranchName>
        <entry>
          <string>refs/remotes/origin/master</string>
          <hudson.plugins.git.util.Build>
            <marked plugin="git-client@1.19.1">
              <sha1>3c202cd190e10e469d749ff13ffce0e64affce7f</sha1>
              <branches class="list">
                <hudson.plugins.git.Branch>
                  <sha1 reference="../../../sha1"/>
                  <name>refs/remotes/origin/master</name>
                </hudson.plugins.git.Branch>
              </branches>
            </marked>
            <revision reference="../marked"/>
            <hudsonBuildNumber>1433</hudsonBuildNumber>
          </hudson.plugins.git.util.Build>
        </entry>
      </buildsByBranchName>
      <lastBuild reference="../buildsByBranchName/entry/hudson.plugins.git.util.Build"/>
      <remoteUrls>
        <string>git@github.com:Magnetme/repo.git</string>
      </remoteUrls>
</hudson.plugins.git.util.BuildData>

And here's the 2.4.1 output

<hudson.plugins.git.util.BuildData plugin="git@2.4.1">
      <buildsByBranchName/>
      <lastBuild>
        <marked plugin="git-client@1.19.1">
          <sha1>9cb02a46a4e9eaaa7432da4b16f803fd7cec709d</sha1>
          <branches class="list">
            <hudson.plugins.git.Branch>
              <sha1 reference="../../../sha1"/>
              <name>refs/remotes/origin/master</name>
            </hudson.plugins.git.Branch>
          </branches>
        </marked>
        <revision reference="../marked"/>
        <hudsonBuildNumber>1403</hudsonBuildNumber>
      </lastBuild>
      <remoteUrls>
        <string>git@github.com:Magnetme/repo.git</string>
      </remoteUrls>
    </hudson.plugins.git.util.BuildData>

I noticed that the way branch information is stored is different from 2.4.0, and the buildsByBranchName is empty. However, branch information is stored in another element called branches. Maybe the bug is that it tries to retrieve the info from the wrong element?

Here's a sample of the build.xml of the job that builds everything but master. I ommitted all but one entry to save space.

<hudson.plugins.git.util.BuildData plugin="git@2.4.1">
<buildsByBranchName>
<entry>
          <string>origin/redirect-frontend</string>
          <hudson.plugins.git.util.Build>
            <marked plugin="git-client@1.19.1">
              <sha1>a617b48a11d3f1e80cb2e76ec6b419222ed6ec89</sha1>
              <branches class="list">
                <hudson.plugins.git.Branch>
                  <sha1 reference="../../../sha1"/>
                  <name>origin/redirect-frontend</name>
                </hudson.plugins.git.Branch>
              </branches>
            </marked>
            <revision plugin="git-client@1.19.1">
              <sha1 reference="../../marked/sha1"/>
              <branches class="list">
                <hudson.plugins.git.Branch reference="../../../marked/branches/hudson.plugins.git.Branch"/>
              </branches>
            </revision>
            <hudsonBuildNumber>3572</hudsonBuildNumber>
          </hudson.plugins.git.util.Build>
        </entry>
      </buildsByBranchName>
      <lastBuild reference="../buildsByBranchName/entry[26]/hudson.plugins.git.util.Build"/>
      <remoteUrls>
        <string>git@github.com:Magnetme/repo.git</string>
      </remoteUrls>
    </hudson.plugins.git.util.BuildData>

Alex Nederlof added a comment - 2015-12-30 11:04 - edited In case it helps, here's the 2.4.0 output: <hudson.plugins.git.util.BuildData plugin= "git@2.4.0" > <buildsByBranchName> <entry> <string> refs/remotes/origin/master </string> <hudson.plugins.git.util.Build> <marked plugin= "git-client@1.19.1" > <sha1> 3c202cd190e10e469d749ff13ffce0e64affce7f </sha1> <branches class= "list" > <hudson.plugins.git.Branch> <sha1 reference= "../../../sha1" /> <name> refs/remotes/origin/master </name> </hudson.plugins.git.Branch> </branches> </marked> <revision reference= "../marked" /> <hudsonBuildNumber> 1433 </hudsonBuildNumber> </hudson.plugins.git.util.Build> </entry> </buildsByBranchName> <lastBuild reference= "../buildsByBranchName/entry/hudson.plugins.git.util.Build" /> <remoteUrls> <string> git@github.com:Magnetme/repo.git </string> </remoteUrls> </hudson.plugins.git.util.BuildData> And here's the 2.4.1 output <hudson.plugins.git.util.BuildData plugin= "git@2.4.1" > <buildsByBranchName/> <lastBuild> <marked plugin= "git-client@1.19.1" > <sha1> 9cb02a46a4e9eaaa7432da4b16f803fd7cec709d </sha1> <branches class= "list" > <hudson.plugins.git.Branch> <sha1 reference= "../../../sha1" /> <name> refs/remotes/origin/master </name> </hudson.plugins.git.Branch> </branches> </marked> <revision reference= "../marked" /> <hudsonBuildNumber> 1403 </hudsonBuildNumber> </lastBuild> <remoteUrls> <string> git@github.com:Magnetme/repo.git </string> </remoteUrls> </hudson.plugins.git.util.BuildData> I noticed that the way branch information is stored is different from 2.4.0, and the buildsByBranchName is empty. However, branch information is stored in another element called branches . Maybe the bug is that it tries to retrieve the info from the wrong element? Here's a sample of the build.xml of the job that builds everything but master. I ommitted all but one entry to save space. <hudson.plugins.git.util.BuildData plugin= "git@2.4.1" > <buildsByBranchName> <entry> <string> origin/redirect-frontend </string> <hudson.plugins.git.util.Build> <marked plugin= "git-client@1.19.1" > <sha1> a617b48a11d3f1e80cb2e76ec6b419222ed6ec89 </sha1> <branches class= "list" > <hudson.plugins.git.Branch> <sha1 reference= "../../../sha1" /> <name> origin/redirect-frontend </name> </hudson.plugins.git.Branch> </branches> </marked> <revision plugin= "git-client@1.19.1" > <sha1 reference= "../../marked/sha1" /> <branches class= "list" > <hudson.plugins.git.Branch reference= "../../../marked/branches/hudson.plugins.git.Branch" /> </branches> </revision> <hudsonBuildNumber> 3572 </hudsonBuildNumber> </hudson.plugins.git.util.Build> </entry> </buildsByBranchName> <lastBuild reference= "../buildsByBranchName/entry[26]/hudson.plugins.git.util.Build" /> <remoteUrls> <string> git@github.com:Magnetme/repo.git </string> </remoteUrls> </hudson.plugins.git.util.BuildData>

Lars Fronius added a comment - 2016-01-06 10:58

We are also affected by this - the GIT_PREVIOUS_SUCCESSFUL_COMMIT pointed to a build that was definitely a Failed build in Jenkins. However, our git plugin was 2.4.0 and Jenkins was at 1.642 when we discovered the wrong behaviour and an update to 2.4.1 / 1.643 did not change it.

So I am thinking the wrong behaviour must have been introduced before the release mentioned in this issue.

Lars Fronius added a comment - 2016-01-06 10:58 We are also affected by this - the GIT_PREVIOUS_SUCCESSFUL_COMMIT pointed to a build that was definitely a Failed build in Jenkins. However, our git plugin was 2.4.0 and Jenkins was at 1.642 when we discovered the wrong behaviour and an update to 2.4.1 / 1.643 did not change it. So I am thinking the wrong behaviour must have been introduced before the release mentioned in this issue.

Jey Saba added a comment - 2016-01-25 21:07

I'm also experiencing the issue of commit changes not being set for each build. Like others here, I am seeing the problem only in some of the jobs on my server.

I've narrowed down the issue to the inclusion of the Prune stale remote-tracking branches option in Additional Behaviours.

I can also confirm that I started seeing this symptom after upgrading from 2.4.0 to 2.4.1, running Jenkins 1.625.3 LTS.

Jey Saba added a comment - 2016-01-25 21:07 I'm also experiencing the issue of commit changes not being set for each build. Like others here, I am seeing the problem only in some of the jobs on my server. I've narrowed down the issue to the inclusion of the Prune stale remote-tracking branches option in Additional Behaviours. I can also confirm that I started seeing this symptom after upgrading from 2.4.0 to 2.4.1, running Jenkins 1.625.3 LTS.

Mark Waite made changes - 2016-02-01 05:20

Link

New: This issue is related to ~~JENKINS-29482~~ [ ~~JENKINS-29482~~ ]

Assignee:: Mark Waite

Reporter:: Alex Nederlof

Votes:: 1 Vote for this issue

Watchers:: 6 Start watching this issue

Created:: 2015-12-29 15:03

Updated:: 2019-10-23 01:28

Resolved:: 2016-02-02 13:04

Jenkins

Details

Description

Attachments

Issue Links

Activity

Collapse comment: Alex Nederlof added a comment - 2015-12-29 15:27, Edited by Alex Nederlof - 2015-12-29 15:27

Expand comment: Alex Nederlof added a comment - 2015-12-29 15:27, Edited by Alex Nederlof - 2015-12-29 15:27

Collapse comment: Mark Waite added a comment - 2015-12-30 01:33, Edited by Mark Waite - 2015-12-30 01:35

Expand comment: Mark Waite added a comment - 2015-12-30 01:33, Edited by Mark Waite - 2015-12-30 01:35

Collapse comment: Alex Nederlof added a comment - 2015-12-30 10:54

Expand comment: Alex Nederlof added a comment - 2015-12-30 10:54

Collapse comment: Alex Nederlof added a comment - 2015-12-30 11:04, Edited by Alex Nederlof - 2015-12-30 11:05

Expand comment: Alex Nederlof added a comment - 2015-12-30 11:04, Edited by Alex Nederlof - 2015-12-30 11:05

Collapse comment: Lars Fronius added a comment - 2016-01-06 10:58

Expand comment: Lars Fronius added a comment - 2016-01-06 10:58

Collapse comment: Jey Saba added a comment - 2016-01-25 21:07

Expand comment: Jey Saba added a comment - 2016-01-25 21:07

People

Dates