Why does a minimum number of builds mean that all builds must be successful in the PR?

Why does a failed build mean that the PR must be rejected and started over for allowing the merge to keep moving forward. If there was a failed build and then a fix and three successful builds (and a minimum of 2 successful builds required), why should a whole new PR be required?


This is on the PR settings screen -"If there are more than the specified number of builds, all of them will have to be successful in order to merge the pull request"



3 answers

1 vote
Roger Barnes Atlassian Team Sep 27, 2015

Hi Mark,

The requirement that all builds pass in the pull request merge checks was a design choice, the theory being that any build result submitted was deemed important. We've no timeline for this but one improvement we're trialling is one where you can specify which builds count towards the merge check. This lets non-critical builds be submitted without preventing a merge. Feel free to get in touch if you'd like to take it for a spin and I'll see if we've got something we can share.

I'd like to check this out if I can. Let me know how it would work. Thanks.

I reproduce this issue on Jenkins and seems related to same needs

Bitbucket jenkins plugin trigger 2 builds and create 2 jobs: on the branch and on pull request

On pull request we defined mandatory tasks to execute before the merge

On Branch the full pipeline we can have errors and do not want to block merge

I defined pull requests: requires a minimum of successful build to 1

If branch fail and not the pull request build I could not merge

pull requests status: 2 builds (1 success, 1 failed)

Why this parameter is not used?

Why Bitbucket do not check the pull request build only? Could be an option?

Hello - I have come across this article after trying to understand the necessaity of scrapping the PR if any builds have failed (regardless if they have later been fixed).

Previously, I have used GitHub, which works in the manner that only the latest build is relevant. i.e. a Pull Requester has a failing build, but can fix the build by adding a new commit to the PR, which automatically triggers a rebuild, and if green, can then be merged. Another scenario that would frequently happen is if you had create two PRs to two sepearte repo's (e.g. first one being a commons repo) - here the second repo would fail until the first PR is merged.

In BitBucket's case, it seems that you have to scrap the PR, and then re-create it - is there anyway to match GitHub's method?


Hi Mark,

A build is tied to an individual commit, so the "number of builds" merge check only looks at the builds associated with the latest commit on the pull request source branch. If you push a fix to your branch, this should trigger a fresh set of builds that will be tied to the new commit - you shouldn't typically have a variable number of builds for each commit. 

In the case where your build fails due to a problem that can be fixed without pushing a new commit (e.g. an environmental problem with the build server), the build status will be automatically updated when the build is re-run provided that it posts the same build key to Stash. 

You can read a bit more about how build statuses are created and updated here: https://developer.atlassian.com/stash/docs/latest/how-tos/updating-build-status-for-commits.html

Hope this helps!


Thanks for the quick response. That answers one part of my questions with the environment issue. But going back to a new commit to an existing PR. Is there no way to get all clear with an enabled merge button if a new commit is necessary to fix the build problem?

The PR shows the builds lodged against the latest commit on the source branch, so if you add a new commit (to fix a build problem) the build statues should be cleared automatically. Are you seeing something different?

"you shouldn't typically have a variable number of builds for each commit"

This assumption is incorrect. One commit can be part of an unlimitted number of branches. A build system working with branches instead of commits (like Bamboo), does not work well with this Bitbucket setting.

I received this from my customer. " I reproduced it just now:

The git-stash-tranining build #3 is triggered on the feature/test-PR branch.  The training-Pull-Request build #4 is the build triggered on the pull request."
Is this an acceptable example?
I'll get the images and attach them in an hour. 

Suggest an answer

Log in or Sign up to answer
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Posted Jun 12, 2018 in Bitbucket

Do you use any Atlassian products for your personal projects?

After spinning my wheels trying to get organized enough to write a book for National Novel Writing Month (NaNoWriMo) I took my affinity for Atlassian products from my work life and decided to tr...

24,010 views 26 12
Join discussion

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