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:

      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

          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
            7 older comments
            Hide
            Permalink
            kakapo4 Mark Wright added a comment -

            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()
            Show
            kakapo4 Mark Wright added a comment - 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()
            Hide
            Permalink
            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
            Permalink
            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
            Permalink
            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
            Permalink
            llibicpep 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.

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

              People

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

                Dates

                Created:
                Updated: