BitBucket does not update refspec for PR, causing Jenkins to build old commits

Question

I am using a local BitBucket server with Git. I am trying to get started with Continous Integration so I\'ve set up a local Jenkins instance. The goal is to have Jenkins check o

Answer 1

Full disclosure: I work for Atlassian's Premier Support team.

First of all, this isn't a bug - it's worth noting that pull request refs (under refs/pull-requests/*) are an implementation detail of Bitbucket Server. They are not intended to be used for CI, or generally relied upon for development. This comment by one of our developers lists some of the reasons why it might not be a good idea to build these refs in CI.

To give you a more technical background, these refs are only created when the pull requests are viewed - they're not eagerly created. Further, the refs under /refs/pull-requests/* may be updated at any time - any change to the source or target branch will result in the pull request being rescoped, but this rescoping event is not guaranteed to be instantaneous and may be enqueued alongside other system events. This is one of the main reasons why we don't recommend building off them. There are other good reasons not to build off these refs - considering the following scenario:

• Sarah at Apple opens PR #123 in ios-core, to merge feature/hologram-ui-support into develop (I know, I'm a dreamer)
• refs/pull-requests/123 is created, and a CI build runs for the feature/hologram-ui-support PR
• Meanwhile, Ahmed merges bug/weird-apfs-edge-case into develop. This causes refs/pull-requests/123 to be rescoped because the target branch has changed, and another CI build runs for the feature/hologram-ui-support PR
• Jane merges feature/siri-asimov-laws-of-robotics-support into develop. refs/pull-requests/123 is rescoped again, and another CI build runs for the feature/hologram-ui-support PR

You can see what I mean - because those refs get rescoped on changes to the target as well as the source branch, it results in a lot more CI builds than you might be expecting. This is likely to be very taxing for your CI server, as effectively every merged PR will trigger a build of every open PR.

Generally speaking I'd recommend one of two approaches:

1. Build the merge in your CI build:
   • Trigger builds on changes to the source branch, and have your build plan do something like git checkout target; git merge source as a build step. Most CI systems should have native support for this kind of workflow.
2. If you must build off refs/pull-requests/, do so only on refs/pull-requests/<id>/merge-clean. There are other merge types here that are inherently failure cases: merge-conflicted and merge-base, so there's no point even trying to build those.

Cheers,

Dave

Answer 2

See Daves answer for an explanation on why this "problem" arise and why Bitbucket is designed in this way.

However i was able to solve my specific problem by changing the settings in the Jenkin-plugin, to "trick" Bitbucket into updating the refs.

By setting the option Build only if Stash reports no conflicts to true in Jenkins (Under Build Trigger for the job), you force Bitbucket to update the refs which means you will check out the correct commit

See https://github.com/nemccarthy/stash-pullrequest-builder-plugin/issues/75 for details