I was able to get the changeset using the following:

checkout scm: [
    $class: 'GitSCM',
    branches: [[name: env.BRANCH_NAME]],
    extensions: [
        [
            $class: 'ChangelogToBranch',
            options: [
                compareRemote: 'origin',
                compareTarget: 'master'
            ]
        ]
    ],
    userRemoteConfigs: [
        [
            url: scm.getUserRemoteConfigs()[0].getUrl(),
            refspec: scm.getUserRemoteConfigs()[0].getRefspec(),
            credentialsId: 'github-privatekey'
        ]
    ]
]

With the above I can get a changeset from the first build.

markewaite what are your thoughts on having `changeset` support a remote ref variable with a default being an empty string, that way a user can specify the base remote ref and that can be used to help the plugin decide how to compute the changeset/changelog. The default variable ensures the code is backwards compatible so folks who don't explicitly supply a remote ref gets their old behavior. I have not dug into the code so I don't know if my suggestion is at all realistic.

bjhaid the plugin has the concept of a base branch for comparison. Users that are willing to use the base branch to compute the changelog might be able to see changelogs on the first commit, though that changelog will be incorrect if their actual base branch does not match the base branch used to compute the changelog.

As an example, there are two development branches for a GitHub repo, one named 'master' and one named 'stable-3.x'. If the Jenkinsfile declares the changelog should be computed against the 'master' branch, then all pull requests to the 'stable-3.x' branch will incorrectly compute their changelog against the 'master' branch.

Thanks for the response!

> If the Jenkinsfile declares the changelog should be computed against the 'master' branch, then all pull requests to the 'stable-3.x' branch will incorrectly compute their changelog against the 'master' branch.

I understand this concern, do you think documentation should be adequate in covering this concern? Also what are your thoughts on refinement of my suggestion below:

A user can provide a fall through base branch when the plugin cannot correctly compute the changelog (i.e on the first commit on a branch), obviously shares similar risks as the original proposal, but in this case it risk is much less, and will still need documentation on the risks.

This issue has also been experienced on branches that had been rebased.
If you rebase N-commits, for which thos commits was a part of the last builds changeset, then it will treat the new build as a first time build.

Using ChangelogToBranch could work, but it will add additional boilerplate code to our pipeline, instead of just calling checkout scm.
For use it is useless to configure it for the job, because we do not know the base branch (compareTarget) until the job has started.

Does the git plugin check for changes using the git commit hash or message?

If it detects "first time build", then it should use the latest commit as changeset.
Build #1
> Commit message: "fix: Correct this method"
> First time build. Skipping changelog

Rebase commit, new hash, same message.
Build #2
> Commit message: "fix: Correct this method"
> First time build. Skipping changelog

Does the git plugin check for changes using the git commit hash or message?

It uses the commit hash.

Is it a bug then, when a rebase there are no changes? It is a changed commit and new hash, but it treats it as First time build thus no changes.

djviking I like the definition of "bug" that Gerald Weinberg and Cem Kaner offered. It's a "bug" if it "bugs someone". In the case you're describing, a bug report would be a good way to start the discussions of what you would expect as a user in the case of a rebase.

I believe the current process compares the preceding build to the current build. If there is no path from the preceding build to current build (as would often happen in a rebase), then no changes are displayed.

If you decide to open that issue, please describe what you would like to happen as a user, paying particular attention to the cases where you're assuming that the git plugin knows the base branch from which the pull request started. It doesn't actually know a base branch unless specifically told to show differences against a base branch. Heuristics to guess the base branch are prone to fail in all sorts of unfriendly ways.

Hello, I am experiencing these issues as well using Bitbucket with a Multibranch Pipeline. This is causing issues with using other plugins looking to use the changelog, specifically the Atlassian Jira Cloud plugin.  Here is some logs on the issue:

[Pipeline] {
[Pipeline] stage
[Pipeline]

[Pipeline] // stage
[Pipeline] withEnv
[Pipeline] {
> git config core.sparsecheckout # timeout=10
> git checkout -f a40df9adb4445594d996cb282389acd8c629be8e # timeout=10
[Pipeline] stage
[Pipeline] { (Test Build)

This is the fourth build on a pull request, which is bizzard this is showing as "First Time Build." This causes errors downstream to other plugins:

[Pipeline] jiraSendDeploymentInfo

jiraSendDeploymentInfo: SKIPPED_ISSUE_KEYS_NOT_FOUND_AND_SERVICE_IDS_ARE_EMPTY: No issue keys found in the change log and service ids were not provided. Not sending deployment information to Jira: godeepseltzer.atlassian.net.

mkroell you're describing a very different case than is described by the other comments in this issue. This issue describes that the user would like the git plugin to provide a reliable guess of the commits that compose the first commit in a branch. That causes the first build on a branch to show no changes.

I think the problem you're describing is that a non-initial build has changes but is not correctly calculating those changes.