This looks like the same type of code-path issue described in https://issues.jenkins-ci.org/browse/JENKINS-41996
final scmVars = checkout(scm)
// scmVars may have Git data from either the someGitLibrary or the scmVars
Looks like its caused by https://github.com/jenkinsci/git-plugin/blob/master/src/main/java/hudson/plugins/git/GitSCM.java#L1282-L1317
Revision state returned by Git SCM step is incorrect
Richard Bowater the most direct work around is to compute the SHA1 of the working directory with a call to a shell script, batch script, or powershell script. Refer to the example in a stackoverflow article.
The technique is also in the pipeline script utilities that I use.
Richard Bowater, on (Windows) build-server, we use the following in our scripts as Mark Waite suggests:
def sha = bat(returnStdout: true, script: '@git rev-parse HEAD').trim()
This is not limited to git.
We see the same or a very similar issue using an SVN repo (which includes svn:externals) and shared libraries stored in SVN.
The values returned by def checkoutResults = checkout(scm ...) contain SVN revision numbers that are not the SVN revision checked out.
Since we use this information in the generated Manifest files this is a major problem.
This is a very dangerous bug.
We are often checking out the Jenkinsfile from branch A and then do in the Jenkinsfile:
commit = checkout([$class: 'GitSCM', branches: [[name: otherversion]]
The returned commit id was the one from the initial SCM checkout for the jenkinsfile, not the one specified as checkout() parameter.
This caused that we deployed applications in the wrong version.
Also having the issue.
Any workaround for GIT_PREVIOUS_SUCCESSFUL_COMMIT ?