weird race condition when getting SHA

[rtsai123]

Hi I am seeing a weird issue where the incorrect SHA is populated when getting commit for the latest PR.

In this example the SHA is incorrect which caused the build to fail.

Building in workspace /var/lib/jenkins/jobs/MYREPO/workspace

git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository git config remote.origin.url ssh://git@stashserver:7999/pro/MYREPO.git # timeout=10 Fetching upstream changes from ssh://git@stashserver:7999/pro/MYREPO.git git --version # timeout=10 using GITSSH to set credentials git -c core.askpass=true fetch --tags --progress ssh://git@stashserver:7999/pro/MYREPO.git +refs/pull-requests/:refs/remotes/origin/pr/_ git rev-parse refs/remotes/origin/pr/227/from^{commit} # timeout=10 git rev-parse refs/remotes/origin/origin/pr/227/from^{commit} # timeout=10 *Checking out Revision 893f4b0ff1caa40f4f8afe36386de5ec10f972a3 (refs/remotes/origin/pr/227/from) git config core.sparsecheckout # timeout=10 git checkout -f 893f4b0ff1caa40f4f8afe36386de5ec10f972a3 not the correct sha** git rev-list 893f4b0ff1caa40f4f8afe36386de5ec10f972a3 # timeout=10

If I comment the PR with "Test this please" then the correct SHA gets populated.

Building in workspace /var/lib/jenkins/jobs/MYREPO/workspace

git rev-parse --is-inside-work-tree # timeout=10 Fetching changes from the remote Git repository git config remote.origin.url ssh://git@stashserver:7999/pro/MYREPO.git # timeout=10 Cleaning workspace git rev-parse --verify HEAD # timeout=10 Resetting working tree git reset --hard # timeout=10 git clean -fdx # timeout=10 Fetching upstream changes from ssh://git@stashserver:7999/pro/MYREPO.git git --version # timeout=10 using GITSSH to set credentials git -c core.askpass=true fetch --tags --progress ssh://git@stashserver:7999/pro/MYREPO.git +refs/pull-requests/:refs/remotes/origin/pr/_ git rev-parse refs/remotes/origin/pr/227/from^{commit} # timeout=10 git rev-parse refs/remotes/origin/origin/pr/227/from^{commit} # timeout=10 Checking out Revision 40ef87726c4aa1e773bbf09b54f48413bed60f8c (refs/remotes/origin/pr/227/from) git config core.sparsecheckout # timeout=10 git checkout -f 40ef87726c4aa1e773bbf09b54f48413bed60f8c git rev-list 893f4b0ff1caa40f4f8afe36386de5ec10f972a3 # timeout=10

Has anyone seen this? Could this be a bug or something I'm missing? Thanks, Rob

[nemccarthy]

Is this a problem with the lazy merge being done by stash?

[rtsai123]

Thanks for responding! Yes its seems like it is a problem with the lazy merge. I've also seen weird issue where build gets triggered but it doesn't have the lastest commit. Even though the commit sha is the latest the actual commit doesn't have the latest update.

here is what I have set in RefSpec +refs/pull-requests/:refs/remotes/origin/pr/ Branch Specifier (blank for 'any') origin/pr/${pullRequestId}/from

[johan-bjareholt]

@rtsai123 The reason why you didn't get the latest commit was because bitbucket didn't have enough time to do the merge so the /merge ref was outdated.

I had this issue aswell, and since there was no workaround i fetched /from instead and did the merge locally in each job. Since the pullrequest builder has the source sha and destination sha i put something similar to this at the start of each build

git merge $destinationCommitHash

If you have downstream jobs that are not triggered by this plugin you can simply add a if condition on this command to check if the parameters are available

if [ ! -z "$destinationCommitHash" ]; then
    git merge $destinationCommitHash
fi

Before this workaround every 10-15th build failed because of that race condition which was simply unacceptable. This might be a ugly workaround but at least it works. Have since built over 400 jobs that merges with the target branch without any issues.

[nemccarthy]

This has now been fixed either using @johan-bjareholt suggestion above, the old way of doing the merge locally on the jenkins box (updated readme) OR reading this https://answers.atlassian.com/questions/239988/change-pull-request-refs-after-commit-instead-of-after-approval-or-workaround and testing with setting Build only if Stash reports no conflicts to on, then it forces an update of the branch. This is the best option for most people so Build only if Stash reports no conflicts now defaults to on from 1.7.1