We've got a successful build check that was triggering a failure note as expected. It was fixed in a later commit which triggered a new build.
We're still showing the failed build but it's followed up by multiple successful build and because there is an (ultimately unresolvable without the commit it won't ever contain) failed build for the PR it won't approve the PR.
The note on the Successful Build check is insanity. "If there are more builds than specified above, they are all required to be successful in order to merge the pull request."
This is a great setting but utterly demoralizing to someone who's project fails and they resolve. They can _never_ resolve the PR short of deleting and recreating the PR.
Hi @mboehm
Depending how the CI integration is setup it will update the build status instead of creating a new one, based on a build key. Also checking for no failed builds is useful when you have other tools that report back, for instance, you have your regular build plus Snyk, and it should not allow merges if one of them are failing.
Having said that, Flowie, a Bitbucket app we provided, has more options to configure checks, including for build checks, if you just care about the last build status, like in your scenario for instance.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.