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

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

    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

            Activity

            Hide
            rjbwtr Richard Bowater added a comment - - edited

            I've just run up against this too.

            Fetching changes from the remote Git repository
            Fetching without tags
            Checking out Revision 5cc3005a298d50fa0c2bc919293fcf3b3ed936de (print-env)
            Commit message: "Print more env"
            
            GIT_COMMIT=eb65cd4f46c828362429cbbd2d904f114bb4b801
            GIT_BRANCH=master
            

            Doesn't seem to be an obvious way to work around it? My particular use case is:

            • a global shared library configured to checkout from git
            • a multibranch pipeline configured to load Jenkinsfiles from the shared libraries above

            We're using pipelines to build and test shared libraries before deployment, but branch builds are being unpredictable due to the environment variables being incorrect.

            Show
            rjbwtr Richard Bowater added a comment - - edited I've just run up against this too. Fetching changes from the remote Git repository Fetching without tags Checking out Revision 5cc3005a298d50fa0c2bc919293fcf3b3ed936de (print-env) Commit message: "Print more env" GIT_COMMIT=eb65cd4f46c828362429cbbd2d904f114bb4b801 GIT_BRANCH=master Doesn't seem to be an obvious way to work around it? My particular use case is: a global shared library configured to checkout from git a multibranch pipeline configured to load Jenkinsfiles from the shared libraries above We're using pipelines to build and test shared libraries before deployment, but branch builds are being unpredictable due to the environment variables being incorrect.
            Hide
            markewaite Mark Waite added a comment - - edited

            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.

            Show
            markewaite Mark Waite added a comment - - edited 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.
            Hide
            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
            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.

              People

              • Assignee:
                Unassigned
                Reporter:
                mkobit Mike Kobit
              • Votes:
                8 Vote for this issue
                Watchers:
                12 Start watching this issue

                Dates

                • Created:
                  Updated: