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.
I am linking defect JENKINS-39968 to this one since I have a gut feeling that the root cause of my defect here is probably related to the root cause of this other defect as well. Assuming there is some sort of shared-state within the "checkout" function, and this shared-state is not thread safe, then it could explain why someone might get inconsistent results elsewhere - like in the change logs - when running checkouts in parallel.