Recently I started using Multibranch Pipeline jobs and set up a shared library to avoid code duplication. I have library changes included and the library implicitly loaded, but explicit loading from the Jenkinsfile bears the same effect.

When writing templates for messages with repository changes after each build I discovered that both available change sets have the same URL and revision.

My main checkout located in the Jenkinsfile has its changelog parameter set to false, so I suppose that the two change sets are related to the @script and @libs checkouts which in my case come from two different repositories.

It might be connected to JENKINS-45815, but in this case it's not me who's doing the checkout.

Reproduction steps are as follows.

1. Create a Multibranch Pipeline, configure with repository A, use a Jenkinsfile with the code below.
2. Add a global shared library under Configure System, Global Pipeline Libraries, cofigure with a different repository B, make sure that "Load implicitly" and "Include @Library changes in job recent changes" are checked.
3. Commit some changes to both repositories so that change sets are created during the build.
4. Start a build and watch the output.

Here is the code I used to test the issue.

currentBuild.changeSets.each{ cs ->
    echo "cs = ${cs}"
    cs.revisionMap.each{ k, v ->
        echo "* k = ${k}, v = ${v}"
    }
}

And here's the output I got. These are different change sets and they contain commits from different repositories with valid descriptions. Alas, the data contained in revisions and revisionMap is the same in both cases, despite one of them coming from A repository and the second from B repository.

[Pipeline] echo
cs = hudson.scm.SubversionChangeLogSet@58d9474d
[Pipeline] echo
* k = https://X/A/trunk, v = 56784
[Pipeline] echo
cs = hudson.scm.SubversionChangeLogSet@d544c46
[Pipeline] echo
* k = https://X/A/trunk, v = 56784

I tried using the raw build, too, but it contains the same change set objects.