nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Mark Lang

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

Accepted answers

All comments

TimP

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

Mark Lang

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?

TimP

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?

Mark Lang

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.

Roger Barnes

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

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

Erwan QUEINNEC

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?

Tom Chamberlain

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

Mike Friedrich

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

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

bitbucket

bitbucket-server