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

GitSCM checkout returns same values on second different call

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      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.

        Attachments

          Issue Links

            Activity

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

            Show
            markewaite 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.
            Hide
            abayer Andrew Bayer added a comment -

            Mark Waite - 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.

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

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

              People

              • Assignee:
                Unassigned
                Reporter:
                bspickers Bernd Spickers
              • Votes:
                0 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated: