Specify Pull Request Merge Strategy
Closed this issue · 3 comments
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.
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
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.
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.