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

GitSCM checkout returns same values on second different call

    • Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Minor Minor
    • None
    • Jenkins 2.121.3, Git plugin 3.9.1, Pipeline SCM step 2.6
    • git plugin 4.7.0

      Hi,

      if I run within a pipeline job, the checkout command twice to checkout different commits, the returnvalue of this call has two times the same values, even if the branches and commits are different.

      E.g:

      def scm1 = checkout (changelog: false, poll: false, verboseEnabled: false, scm: [$class: 'GitSCM',
      branches: [[name: 'refs/tags/TAG1']], ....)

      def scm2 = checkout (changelog: false, poll: false, verboseEnabled: false, scm: [$class: 'GitSCM',
      branches: [[name: 'refs/tags/TAG2']], ...)

      the Maps scm1 and scm2 contain the same values, even if the tags are on different commits.

      And the values are always from the first checkout .

      So how can I get such values from the second checkout?

       Note that this problem is specific to performing multiple checkouts from the same repository with different SHA1 hashes in the same Pipeline job. If different repositories are used in the same Pipeline job, refer to JENKINS-39968.

          [JENKINS-53346] GitSCM checkout returns same values on second different call

          Mark Waite added a comment - - edited

          I've confirmed that the bug exists as reported. The map returned by the second checkout has the same values as the map returned by the first checkout.

          Refer to the Jenkinsfile in my JENKINS-53346 test branch for an alternative to obtain the same information using a shell call.

          Mark Waite added a comment - - edited I've confirmed that the bug exists as reported. The map returned by the second checkout has the same values as the map returned by the first checkout. Refer to the Jenkinsfile in my JENKINS-53346 test branch for an alternative to obtain the same information using a shell call.

          Andrew Bayer added a comment -

          markewaite - if I'm remembering the code correctly, this would mean that GitSCM#buildEnvironment(Run,Map) is populating the map passed to it with the same values every time it's called - is that right? If so, I should remove workflow-scm-step-plugin from the components, since we're just calling SCM#buildEnvironment(Run,Map) and trusting it to populate the map with the right things.

          Andrew Bayer added a comment - markewaite - if I'm remembering the code correctly, this would mean that GitSCM#buildEnvironment(Run,Map) is populating the map passed to it with the same values every time it's called - is that right? If so, I should remove workflow-scm-step-plugin from the components, since we're just calling SCM#buildEnvironment(Run,Map) and trusting it to populate the map with the right things.

          Mark Waite added a comment - - edited

          When I look at GitSCM#buildEnvironment(Run, Map) it appears to compute the value for GIT_BRANCH, GIT_LOCAL_BRANCH, GIT_CHECKOUT_DIR, and GIT_COMMIT from build data and last built revision of the workspace.

          The GIT_PREVIOUS_COMMIT, GIT_PREVIOUS_SUCCESSFUL_COMMIT, and GIT_URL are based on the current conditions of the repository.

          However, if the call to buildEnvironment happens before build data is updated for the running build, or if getBuildData(build) returns the same Revision (line 1344) even though there are two different build data values for the checkout, then that may indicate the problem is inside the git plugin and only related to workflow-scm-step because that is what shows the bug in GitSCM. I confess, I'd need a debugger and some test cases before I could be confident where the bug lies.

          Mark Waite added a comment - - edited When I look at GitSCM#buildEnvironment(Run, Map) it appears to compute the value for GIT_BRANCH, GIT_LOCAL_BRANCH, GIT_CHECKOUT_DIR, and GIT_COMMIT from build data and last built revision of the workspace. The GIT_PREVIOUS_COMMIT, GIT_PREVIOUS_SUCCESSFUL_COMMIT, and GIT_URL are based on the current conditions of the repository. However, if the call to buildEnvironment happens before build data is updated for the running build, or if getBuildData(build) returns the same Revision (line 1344) even though there are two different build data values for the checkout, then that may indicate the problem is inside the git plugin and only related to workflow-scm-step because that is what shows the bug in GitSCM. I confess, I'd need a debugger and some test cases before I could be confident where the bug lies.

          Ramon Leon added a comment -

          I've filed a PR with a fix and test, I hope the approach is right: https://github.com/jenkinsci/git-plugin/pull/1050

          Ramon Leon added a comment - I've filed a PR with a fix and test, I hope the approach is right:  https://github.com/jenkinsci/git-plugin/pull/1050

            mramonleon Ramon Leon
            bspickers Bernd Spickers
            Votes:
            1 Vote for this issue
            Watchers:
            6 Start watching this issue

              Created:
              Updated:
              Resolved: