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

    • Similar Issues:
    • Released As:
      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

            Activity

            Hide
            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.

            Show
            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.
            Hide
            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.

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

            Also having the issue.
            Any workaround for GIT_PREVIOUS_SUCCESSFUL_COMMIT ?

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

            Show
            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.
            Hide
            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

            Show
            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

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

                Dates

                Created:
                Updated:
                Resolved: