'Bitrise Build Start' step aborts current workflow if Rolling Builds is set to cancel running builds


#1

We want to start using parallel builds as described on https://blog.bitrise.io/start-multiple-builds-with-the-same-trigger to save a lot of build time.
We have Rolling Builds enabled, and set it to auto-cancel running builds.
Now, as soon as the main workflow starts a second workflow with the ‘Bitrise Build Start’ step, the main workflow gets aborted with reason “Automatically aborted via Rolling Builds.”.

The obvious workaround is to disable the “Running builds” option in the Rolling Builds settings, but this causes a lot of unnecessary builds for us.

This issue is probably related to this feature request: Do not cancel builds on same branch if another workflow is triggered.
I’m filing it as a bug anyway, as I think it is one.


Do not cancel builds on same branch if another workflow is triggered
#2

Hi @jcopini,
thanks for the report! We created a ticket for the tooling team, to fix this.


#3

Hi, any update on this? I just tried to use the Bitrise Build Start step, but can’t use it because of the above issue :frowning:


#4

Hi @marianeum !

Sorry for the delayed answer!
The Tooling Team has a ticket for this, but it’s not solved yet.
For now, you can’t use the “Build Start” step with the Rolling Build option if the “Cancel Running Builds” option is set.

Sorry for the inconvenience.


#5

Thanks for the update! Is there any timeline for a fix? We currently have two tasks which both take 10-15 minutes, which can’t run in parallel because of this issue :frowning: as it’s something that’s running on pull request not using “Cancel running builds” can cause a lot of running builds, so we don’t want to use that at the moment.


#6

Hi @marianeum!

Sorry for the delay and for keeping you waiting! Unfortunately, we can’t really provide an ETA, there is a ton our Tooling Team’s plate sadly but rest assured they are working on resolving this as we speak!

Thanks for your patience and understanding in the while, we will definitely get back to you once we have an update!


#7

Sorry is there any update yet? Would really like to speed up our 35 minutes builds with this.


#8

This is also affecting us


#9

Hi @yonaskolb and @marianeum

Sorry about the delay! Some urgent changes came up and unfortunately so our Tooling team couldn’t prioritize this task due to them, but they are working on resolving this and will notify this thread once they are done.

In the while, feel free to contact us on our on-site chat about these problems to see if there’s something else we could recommend!


#10

Thanks for the update @bitce! We ended having to remove the “Build Build Start” workflows, and putting everything into a single workflow. It’s a lot slower now as things aren’t parallel, but at least builds get auto cancelled on new commits.
Was there a technical reason why Bitrise couldn’t allow multiple workflows to be triggered from the same trigger? (or multiple duplicate trigger conditions that start different workflows)


#11

Hi @yonaskolb, sorry for the awfully long delay here!

As to answer your question, yes, but we are looking to implement this in the future. Please see and vote for our related feature request here: Parallel Builds: Seperate stacks for seperate workflows + trigger multiple workflows (builds) at the same time


#12

Sorry to bother again, but is there any update? We’re now at 45 minutes build times - there’s at least two things running for 10-15 minutes each that could be parallelised, but we’re blocked by this issue.
This is different to the feature request as an existing feature that’s supposed to parallelise steps is not working with rolling builds enabled.
This is wasting a lot of time for us as we have to spend a lot of time waiting for CI to finish and is causing a huge amount of frustration.


#13

@marianeum This is so frustrating! The only work around I can think of is put parallel workflows into separate apps. And use different triggers on them.


#14

@bitce This is getting a little bit ridiculous. It shouldn’t be that hard to fix right? Since all the parallel builds have the same build number, the newer ones could JUST cancel the builds with the same trigger that also have a smaller build number. What’s so hard about that?


#15

@zhubofei we are working on fixing this issue, it should be released soon.


#16

We’ve just rolled out this feature, from now on only builds triggered on the same workflow gets aborted when a new build is started. Thanks for reporting the issue and let me know if you have any questions!