Details
-
Type:
Bug
-
Status: Open (View Workflow)
-
Priority:
Major
-
Resolution: Unresolved
-
Component/s: scm-api-plugin
-
Labels:None
-
Similar Issues:
Description
This looks like the same type of code-path issue described in https://issues.jenkins-ci.org/browse/JENKINS-41996
@Library('someGitLibrary') node { 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
Attachments
Issue Links
- is blocked by
-
-
- Closed
-
Activity
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.
Bram Mertens
added a comment - 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]]
).GIT_COMMIT
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.
Fabian Holler
added a comment - 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]]
).GIT_COMMIT
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 ?
Edouard Lavaud
added a comment - Also having the issue.
Any workaround for GIT_PREVIOUS_SUCCESSFUL_COMMIT ? We had CI pipeline for the shared jenkins lib that uses itself, i.e. new commits being tested and promoted via pipeline using one of the old commits addressed by a tag. Somehow it's being working for years and started to hit us recently. Because of this bug, our pipeline constantly re-promotes what was already there instead of promoting the new code. This sounds like a very critical and dangerous bug as it may let the users promote wrong versions to prod environment and cause an outage.
Dmytro Kryvenko
added a comment - We had CI pipeline for the shared jenkins lib that uses itself, i.e. new commits being tested and promoted via pipeline using one of the old commits addressed by a tag. Somehow it's being working for years and started to hit us recently. Because of this bug, our pipeline constantly re-promotes what was already there instead of promoting the new code. This sounds like a very critical and dangerous bug as it may let the users promote wrong versions to prod environment and cause an outage.
Richard Bowater, on (Windows) build-server, we use the following in our scripts as Mark Waite suggests: