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

buildsByBranchName is not set anymore

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • git-plugin
    • None
    • git-plugin 2.4.1
      Jenkins 1.643

    Description

      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.

      Attachments

        Issue Links

          Activity

            alexnederlof 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

            alexnederlof 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
            markewaite 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.

            markewaite 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.
            alexnederlof 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!

            alexnederlof 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!
            alexnederlof 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>
            
            alexnederlof 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>
            larsfronius 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.

            larsfronius 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.
            jeysaba 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.

            jeysaba 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.
            markewaite 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.

            markewaite 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_issue_link 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
            markewaite Mark Waite added a comment -

            Fixed in git plugin 2.4.2, released 2 Feb 2016

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

            Thanks Mark!

            alexnederlof Alex Nederlof added a comment - Thanks Mark!

            People

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

              Dates

                Created:
                Updated:
                Resolved: