Updating an existing Pull-Request with additional commits leads to broken builds of the Pull Request, because jenkins tries to check out a not existing ref in git.
- create a branch in the repository
- create a new commit
- create a multibranch job building all branches and pull requests
- create a new pull request in Bitbucket server from the new branch to master
- scan for changes in the multibranch job -> the first build of the PR succeeds
- change some files on the branch and commit
with the --amend flag setand push with force flagEdit: Found out, that a normal commit to the branch also crashes the build.
- scan for changes in the multibranch job -> a build in the PR is triggered but fails due to git complaining that the ref does not exist
- After visiting the Pull-Request overview in Bitbucket, following builds succeed
This is the jenkins console output:
I opened an issue at the bitbucket atlassian support and got the answer, that this behavior is by design and one should never checkout refs, which are generated lazily.
This is the full answer from atlassian:
I'm one of the Bitbucket Server developers. The issue you're running into here is from fetching pull request refs. Here's a detailed response I wrote to someone else having a similar issue.
When new commits are pushed to a branch which has an open pull request, the pull request hashes are eagerly updated in the database but the refs on disk are not. This behavior has existed unchanged since pull requests were introduced in Stash 1.3.0. If someone views the pull request, then the refs are updated as part of performing a new merge to show an up-to-date diff. Any integration which attempts to use refs/pull-requests/*/from is going to be racy and unreliable because that ref is not eagerly updated.