Incorrect SHA checked out on completed merge request

Version report

Jenkins and plugins versions report:

Jenkins: 2.289.1
OS: Linux - 3.10.0-957.21.3.el7.x86_64
gitlab-plugin:1.5.20

What Operating System are you using (both controller, and any agents involved in the problem)?

Linux RedHat RHEL7

Gitlab version: 13.12.1

Reproduction steps

Create Jenkins job to be triggered only by accepted merge requests

Including the following in the pipeline script:

checkout ([
        $class: 'GitSCM',
        branches: [[name: "origin/${env.gitlabTargetBranch}"]],
        extensions: [
                [$class: 'PruneStaleBranch'],
                [$class: 'CleanCheckout'],
                [$class: 'LocalBranch', localBranch: env.gitlabTargetBranch]
        ],
        userRemoteConfigs: scm.userRemoteConfigs
    ])

Create and merge a merge request (for example, Develop -> Master)

Results

Expected result:

The latest commit of the target branch is checked out into a local branch with a matching name

Actual result:

The latest commit of the source branch is checked out into a local branch that matches the target branch name

Diagnosis / workaround:

This would appear to be due to the way the webhook from gitlab is handled - the "last_commit" details in the hook are actually those of the head of the branch being merged in. The resulting merge commit sha is actually sent through in the object_attributes.merge_commit_sha field, but it is "last commit" that is checked out and as such the local branch ends up one commit behind the the remote. This causes particular problems when trying to run maven releases - these fail with an error.

The workaround is to add the following as a secondary step after the checkout:

sh "git branch --set-upstream-to=origin/${env.gitlabTargetBranch} ${env.gitlabTargetBranch} && git pull"

However this feels like a hack - shouldn't a completed merge request check out the full result of the merge?

+1 I am encountering the same issue. The last_commit makes sense if the merge is a fast forward. In the case where the merge creates a merge-commit, the SCM checkout should use the object_attributes.merge_commit_sha. If for whatever reason checking out the code at object_attributes.merge_commit_sha is not possible, provide the object_attributes.merge_commit_sha as an env variable so we can check the code out ourselves. This option works sh "git branch --set-upstream-to=origin/${env.gitlabTargetBranch} ${env.gitlabTargetBranch} && git pull" however in the case where many merge requests gets merged in the span of few seconds, object_attributes.merge_commit_sha and git pull will not be the same commit id.

jenkinsci / gitlab-plugin