Details
-
Suggestion
-
Resolution: Unresolved
-
5
-
334
-
Description
As per the recommendation to my question (https://community.atlassian.com/t5/Bitbucket-questions/How-to-manage-pull-request-build-status-with-pipelines-when/qaq-p/840763) raising this bug.
As a code reviewer I want to approve pull request only when a successful full build is completed so that I can be certain only quality code is checked into the main branch.
Result: We have a pipelines build in which the majority of work, including tests, is done in a manually triggered step*. When a check-in occurs the build finishes the first step (which has to be automatic), this marks the build as successful even though subsequent steps have not been attempted. This is problematic when a pull request is started as we also have a branch permission set to require a successful build. The trivial build with only the first step complete satisfies the successful build rule making the rule effectively useless.
Expected Result: The successful build rule is not satisfied until a paused or incomplete build is fully complete.
- This is done for 2 main reasons. 1. We wish to encourage regular check-in but also not use up build minutes. 2. The build uses external limited resources so we also limit concurrent builds by making it a deployment (this is a hack but there is no other way to limit concurrent builds using pipelines).
Attachments
Issue Links
- relates to
-
BCLOUD-23189 Pipelines build completion status icon is inconsistent in Pipelines history vs PR view
- Gathering Impact
- mentioned in
-
Page Loading...