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"
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 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?
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!
"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.
Hello! My name is Mark Askew and I am a Premier Support Engineer for products Bitbucket Server/Data Center, Fisheye & Crucible. Today, I want to bring the discussion that Jennifer, Matt, and ...
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
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs