How to manage pull request build status with pipelines when there is a manually triggered step?

[Warren Mayocchi]

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 rule making it effectively useless. 

Is there a better way to manage pull requests and Pipelines? This seems difficult for a relatively mature product which makes me think we are doing things the wrong way. 

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

[StannousBaratheon · Accepted solution]

Hi @Warren Mayocchi

Unfortunately there's no way to do this in Pipelines currently but it sounds like a useful feature so I would encourage you to raise a feature request via the following URL: https://bitbucket.org/site/master/issues/new

That will allow us to track interest in the feature and prioritise accordingly. You may also be interested in this existing feature request: https://bitbucket.org/site/master/issues/16262/build-concurrency-control-for-non

Regards

Sam

[Warren Mayocchi]

Bug report created: https://bitbucket.org/site/master/issues/16689/incomplete-builds-should-not-be-marked-as