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.
This is VERY FRUSTRATING!!!
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?
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.
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 https://jira.atlassian.com/browse/BSERV-8384. Allowing customization there certainly has merit in its own right. Here's another issue for just removing the commit messages from the bottom https://jira.atlassian.com/browse/BSERV-6980.
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: http://stackoverflow.com/questions/27683077/how-do-you-detect-an-evil-merge-in-git.
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.
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.
Bitbucket Pipelines helps me manage and automate a number of serverless deployments to AWS Lambda and this is how I do it. I'm building Node.js Lambda functions using node-lambda ...
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!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
We're bringing product updates and pro tips on teamwork to ten cities around the world.Save your spot