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"


Thanks,

Mark

3 answers

1 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.

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?

Thanks

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!

Tim

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 Join to answer
Community showcase
Piotr Plewa
Published Dec 27, 2017 in Bitbucket

Recipe: Deploying AWS Lambda functions with Bitbucket Pipelines

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&nbsp...

682 views 0 4
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
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot