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

Revision information produced by pipline 'checkout' operation isn't parallel safe

    Details

    • Type: Bug
    • Status: Open (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: git-plugin, pipeline
    • Labels:
      None
    • Environment:
      Jenkins v2.148
      Pipeline Plugin v2.5
      Git Plugin v3.9.1
      Git Client Plugin v2.7.3
    • Similar Issues:

      Description

      I recently ran some test builds on our build farm to check out the "new" return data produced by the scm "checkout" function. In our case we are using Git as our source repository and are doing checkouts using code that looks like this:

       

      def branchName = "MyBranch"
      def res = checkout (
          changelog: true,
          poll: false,
          scm: [
              $class: 'GitSCM',
              branches: [[name: branchName]],
              browser: [$class: 'GitLab', repoUrl: "path/to/repo', version: "10.0"],
              doGenerateSubmoduleConfigurations: false,
              extensions: [
                  [$class: 'CloneOption', depth: 0, noTags: false, reference: '', shallow: false, timeout: 90],
              ],
              submoduleCfg: [],
       
              userRemoteConfigs: [[credentialsId: 'git_creds', url: "path/to/repo.git"]]
      ]
      )
      echo "Results from checkout are " + res.toString()
       
      This code works well enough on it's own, until you try to run it in parallel. In our case we have 2 parallel stages that are set up to check out code from the same Git repository but that use 2 different branches. When you examine the output produced by the "echo" statement at the end of the snippet you will see that the revision information returned (ie: res.GIT_COMMIT) reflects the correct revision number for the "first" clone operation that runs, but it does NOT for the "second" clone operation (dependent upon which of the parallel stages runs first). The second clone operation to run seems to be returning result data from the first clone operation, almost like the two clone processes are sharing common data behind the scenes or something. This makes it impossible to rely on the results of a "checkout" call when performing the operation in parallel.

        Attachments

          Issue Links

            Activity

              People

              • Assignee:
                Unassigned
                Reporter:
                leedega Kevin Phillips
              • Votes:
                1 Vote for this issue
                Watchers:
                4 Start watching this issue

                Dates

                • Created:
                  Updated: