BitBucket Pull Request/Merge Commit Messing Up JIRA Workflow

Here's the situation...

We user JIRA, Fisheye/Crucible and Bitbucket Server.  We have a JIRA worflow set up so that we can't resolve an issue if there are any unreviewed commits against it.  Coding is done on feature branches and after the code has been reviewed we merge the code to the main branch. 

If the branch is merged BEFORE we resolve the JIRA issue, the issue CANNOT be resolved. 

This is because the pull request/merge in Bitbucket adds all commit messages to the merge commit.  JIRA now thinks another commit has been made against the issue won't allow it to be resolved.  You can create a review in Crucible for the commit, but since there are no files added to the review, closing it has no impact on JIRA thinking that there are outstanding commits that need to be reviewed and so we're stuck.


When completing the merge in Bitbucket, there is a message text box that is empty.  As part of completing the merge, Bitbucket adds all commit messages in the background.  Adding your own message doesn't overwrite this, the commit messages are simply appended after it.

Is there any way to disable Bitbucket from adding the commit messages to merges?

3 answers

0 votes
Adam Ahmed Atlassian Team Oct 27, 2016

Could you tell me more about this JIRA workflow that means you "can't resolve an issue if there are any unreviewed commits against it"? I'm a bit confused about why it cares about commit messages. That said, if it does care about commit messages, it could look for "Merge pull request #" at the start of the commit message to discount those commits.

If you add the JIRA issue in the commit message (e.g. JIRA-1), JIRA associates the commit with the issue.  This is built in to JIRA so I can't tell it to ignore/discount commits.  I should have control over the merge commit message in Bitbucket.

0 votes
Adam Ahmed Atlassian Team Oct 28, 2016

Thanks Shelli,

There's currently no way to alter the commit message used when merging - your changes are always additive. If you'd like to be able to edit the full message, I'd suggest voting for and watching Allowing customization there certainly has merit in its own right. Here's another issue for just removing the commit messages from the bottom

I understand this is a matter of opinion, but I still believe the problem is not that the merge is associated to the JIRA issue. I'd say it arguably should be linked there since it's the commit whose sole purposes was to merge the issue changes into your stable branch, but reasonable people can disagree.

I assume you're using a custom plugin because the "Unreviewed code" warning in the Releases/Version report in JIRA doesn't seem to have this problem and I couldn't find a plugin on Marketplace that seemed to cover this - let me know if you're not. I'd suggest modifying the plugin you use to identify "unreviewed" commits to start ignoring merges whose message starts with "Merge pull request #". Barring malicious committers, this will safely ignore Bitbucket's automated commits.

Alternatively you could have the plugin ignore all non-"evil" merges. That is, merges where nothing was changed in the commit itself; the merge simply combines the changes from its parent commits. This is safest since it means nothing can be snuck into the merge and avoid review, but it's non-trivial to implement:

Lastly, a workaround might be to enforce -ff-only merges in Bitbucket PRs, but assuming you want the merge commits in your history, it's probably not a good workaround.

Hope that helps.



You assume wrong. 

I am using built in JIRA transition conditions on a workflow to ensure that all commits against a JIRA issue are reviewed in Crucible.  Perhaps you should speak with your colleagues at Atlassian who are more knowledgeable about JIRA than you before making assumptions.

I also consider myself to be a reasonable person and I thoroughly disagree that all previous commit messages should be in the merge commit message.

Thank you for answering the question that it is not possible to update the merge message in Bitbucket. Since this breaks our workflow, we will not be using Bitbucket to do pull requests/merges but do it locally on our machines before pushing to Bitbucket.

Adam Ahmed Atlassian Team Nov 01, 2016

Thanks for clarifying Shelli. Unsurprisingly, this is not the first time I've been wrong and I'm quite open to it (hence "let me know if you're not"). When you said you were using Crucible and Bitbucket Server, I didn't expect you'd use both Crucible reviews and BBS PRs on the same issue - that's rare. If you have details on why you're doing that, it might help us improve our products, so I'd be grateful to hear them.

I also hope you weren't offended by "reasonable people can disagree" phrase. I simply meant to say that "reasonable people may very likely disagree with me" and I certainly understand if you disagree - my opinion there isn't by any means "better" than the converse opinion.

Best of luck, and definitely watch BSERV-6980 if you're interested in the fix for this.

We don't do reviews in Bitbucket.  We were simply trying to use Bitbucket pull requests to have control over how merges are done/approved by a designated "gatekeeper".

Adam Ahmed Atlassian Team Nov 02, 2016

Ok, cool. Cheers!

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Mar 14, 2019 in Bitbucket Pipelines

Building a Bitbucket Pipe as a casual coder :  #!/bin/bash source "$(dirname "$0")/" enable_debug extra_args="" if [[ "${DEBUG}" == "true" ]]; then extra_args="--verbose" fi # mandatory variables R...

250 views 0 12
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you