jenkinsci/bitbucket-branch-source-plugin

Specify Pull Request Merge Strategy

Closed this issue · 3 comments

Aposhian commented

What feature do you want to see added?

There is no configurability on how Pull Requests are merged with the target branch when Merging the pull request with the current target branch revision is selected. However, in Bitbucket, you can select your PR merge strategy from:

  • Merge commit (git merge --no-ff)
  • Squash (git merge --squash)
  • Fast forward (git merge --ff-only)

This means that you can't necessarily guarantee that your PR is building with same source tree that it will eventually be merged as. Even though these things are inherently decoupled, adding configurability in the Bitbucket Branch Source Plugin would allow teams to configure their PRs to build a certain way, and then make sure they merge with the same strategy.

This is important because different merge strategies produce different git hashes, which may be used to track revisions or intermediate artifacts.

Upstream changes

Upstream changes to scm-api-plugin seem unlikely, since these merge strategies are Git specific. Bitbucket Cloud only supports Git now, but I'm sure there are still people using Bitbucket Server with Mercurial, so adding this feature in a backward compatible way might be tricky.

KalleOlaviNiemitalo commented

different merge strategies produce different git hashes

Even if both Jenkins and Bitbucket Server make a merge commit, I expect the merge commit IDs will differ because the committer time stamps will differ.

I'm sure there are still people using Bitbucket Server with Mercurial

Bitbucket Server never supported Mercurial, even though it was a popular request. BSERV-2469

  • 👍2
Aposhian commented

Thank you for the clarification. That does somewhat lessen the need for this feature for my purposes, although I'm not sure if there are others who would find this useful.

lifeofguenter commented

I agree, the very nature of Git is that it you would rather use the default branch as single source of trust. Simulating the same type of Git merge strategy might only add very little to that confidence.

Instead a common strategy would be to run tests even on a default-branch build and/or work with release trains/dev-branch if more caution is required.