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

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.

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!

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>

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.

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.

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

Fixed in git plugin 2.4.2, released 2 Feb 2016

Thanks Mark!