• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • git-plugin
    • None
    • git-plugin 2.4.1
      Jenkins 1.643

      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.

          [JENKINS-32218] buildsByBranchName is not set anymore

          Alex Nederlof added a comment - - 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 - - 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 added a comment - - 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 - - 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 -

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

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

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

          I found that reverting c1872d from the git plugin resolves this bug and JENKINS-29482. I'll need to work with @ndeloof to see if there is another way to include that improvement without breaking plugin changelog when pruning stale branches.

          Mark Waite added a comment - I found that reverting c1872d from the git plugin resolves this bug and JENKINS-29482 . I'll need to work with @ndeloof to see if there is another way to include that improvement without breaking plugin changelog when pruning stale branches.

          Code changed in jenkins
          User: Mark Waite
          Path:
          src/main/java/hudson/plugins/git/extensions/impl/PruneStaleBranch.java
          src/main/java/hudson/plugins/git/util/BuildData.java
          http://jenkins-ci.org/commit/git-plugin/336c1787c7b967e4220c4d459092397fda29892a
          Log:
          [Fix JENKINS-29482] Don't prune stale branches from BuildData

          This reverts commit c1872d038cc2f584bafbc375744deb54a1dbe316.

          Git plugin 2.4.1 included c1872d0 which regressed the plugin and
          introduced JENKINS-32218

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Mark Waite Path: src/main/java/hudson/plugins/git/extensions/impl/PruneStaleBranch.java src/main/java/hudson/plugins/git/util/BuildData.java http://jenkins-ci.org/commit/git-plugin/336c1787c7b967e4220c4d459092397fda29892a Log: [Fix JENKINS-29482] Don't prune stale branches from BuildData This reverts commit c1872d038cc2f584bafbc375744deb54a1dbe316. Git plugin 2.4.1 included c1872d0 which regressed the plugin and introduced JENKINS-32218

          Mark Waite added a comment -

          Fixed in git plugin 2.4.2, released 2 Feb 2016

          Mark Waite added a comment - Fixed in git plugin 2.4.2, released 2 Feb 2016

          Alex Nederlof added a comment -

          Thanks Mark!

          Alex Nederlof added a comment - Thanks Mark!

            markewaite Mark Waite
            alexnederlof Alex Nederlof
            Votes:
            1 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: