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.