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

checkout(scm) step can return wrong variables when used following another Git checkout

    XMLWordPrintable

Details

    • git plugin 4.7.0 released 17 Mar 2021

    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

          duplicates

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-53346 GitSCM checkout returns same values on second different call

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Closed
          is blocked by

          Bug - A problem which impairs or prevents the functions of the product. JENKINS-52378 Revision state returned by Git SCM step is incorrect

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Closed

          Activity

            Ascending order - Click to sort in descending order
            View 8 older comments
            bram_mertens 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.

            bram_mertens 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.
            fho 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.

            fho 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.
            elavaud Edouard Lavaud added a comment -

            Also having the issue.
            Any workaround for GIT_PREVIOUS_SUCCESSFUL_COMMIT ?

            elavaud Edouard Lavaud added a comment - Also having the issue. Any workaround for GIT_PREVIOUS_SUCCESSFUL_COMMIT ?
            llibicpep Dee 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.

            llibicpep Dee 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.
            markewaite Mark Waite added a comment -

            Git plugin 4.7.0 returns the expected value from checkout scm. As far as I can tell, this should be resolved in multibranch pipelines and organization folders thanks to the fix for JENKINS-53346

            markewaite Mark Waite added a comment - Git plugin 4.7.0 returns the expected value from checkout scm . As far as I can tell, this should be resolved in multibranch pipelines and organization folders thanks to the fix for JENKINS-53346

            People

              Unassigned Unassigned
              mkobit Mike Kobit
              Votes:
              9 Vote for this issue
              Watchers:
              16 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: