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

This feature request is also applicable for the situation when the "Allow automatic merge when builds pass" settings is enabled in the branch restrictions. If a build has manually-triggered steps, which include deployments that are manually triggered, it will be considered successful, so long as the steps that were automatically triggered are complete as successful.