Details
-
Suggestion
-
Resolution: Duplicate
Description
A bit of a follow-up to BCLOUD-5652 using the ability to pass build results over the API from our CI servers.
I'd like to see a successful build requirement on a pull request before it can be merged. This will greatly help in actually enforcing successful tests before something is deployed to a production branch.
Note that this might be more complicated than it first looks. I do not want it to just be rejected if there is a failed build, because if I have multiple build configurations configured for a branch and not all of them have completed, the lack of failure doesn't mean anything. In other words, the ideal solution would be specifying the names (or IDs) of build configurations that explicitly have to finish with a successful state before merging is possible.
This should of course always be enforced on the latest commit in a pull request. If a previous commit had all successful builds but there is a new commit that is awaiting new builds, the entire pull request is currently still marked as successful, which isn't technically correct. Especially for this use case, the enforcement should always happen on the latest commit (since that is the state that matters for merging).