It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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

Mark Lang Community Leader Sep 19, 2015

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

2 votes
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.

Mark Lang Community Leader Sep 27, 2015

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?


Like Mark Roddy likes this

@Roger Barnes - has this "where you can specify which builds count towards the merge check" been implemented?
Is there any ticket/feature request we can track?
Thanks in advance!

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:

Hope this helps!


Mark Lang Community Leader Sep 20, 2015

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.

0 votes
Mark Lang Community Leader Sep 21, 2015
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
Community showcase
Published in Bitbucket

Atlassian supported Jenkins integration for Bitbucket Server

We’ve been building a plugin to integrate Bitbucket Server and Jenkins CI, and I’m excited to announce that our alpha is ready to download and install. It lets you seamlessly configure a Jenkins job ...

431 views 0 9
Read article

Community Events

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

Find an event

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

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you