Rolling Builds to cancel all builds related to Bitrise Start Build

Feature Requests Builds
1

Description of the feature request

I just realized that Rolling Builds settings don’t currently work, or at least do not bring the optimal/expected effect when we want to trigger more than one build (via Bitrise Start Build) for a given PR/push/tag (via trigger map).

Let’s say that when you push something to the PR pr_to_develop kicks in and enqueues two builds - mac_tests and ios_tests (Bitrise Start Build). When we make another push to that PR and mac_tests and ios_tests builds are still in progress - they won’t get canceled, cause currently Rolling Builds knows only about pr_to_develop and can cancel that at most (unlikely cause it’s pretty brief). Instead, new builds will be enqueued. Sth like that happens:

IMG_FD4265E6C789-1
IMG_FD4265E6C789-11920×2561 148 KB

I have seen a ton of discussions/feature requests where people ask to develop a one-to-many (trigger to workflows) feature for trigger map, and as far as I see - we’re not getting into that direction. In such a situation it would be nice to at least improve that behavior.

Use case / for what or how I would use it

When triggering multiple builds via Bitrise Start Build and Rolling Builds setting is enabled.

2

Hello,

I will be happy to include this as a feature request. Quick question - what about manually started builds? If there is a build against same branch/same workflow that is running or waiting that was manually started, should it also be cancelled? And would you want a manually started build (same branch/workflow) to cancel any triggered builds (triggered by webhook or by Bitrise Start Build)?

1 Like
3

Hi @cathy.harmon,

Thanks for the reply! Let me make sure that I got you. You mean such a scenario (in my the context of my example):

  1. User manually enqueues mac_tests
  2. Then somebody (hook or Bitrise Start Build) triggers pr_to_develop
    And another scenario:
  3. We have a mac_tests (triggered by pr_to_develop) running
  4. We create mac_testsmanually
    Right?

I’m not 100% sure, but I guess the same/normal/single-workflow rolling builds canceling strategy can be applied here. In general, I think it would be simpler to make it without mixing manuals/hooks and possibly then look for improvement :slight_smile: