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).
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.