Parallel Builds: trigger multiple workflows (builds) at the same time - build stages - fan-out fan-in support

+1, are there any updates/is there an estimated release date for this feature?

@yonas & @laurajohannet, this is still the status: Parallel Builds: Seperate stacks for seperate workflows + trigger multiple workflows (builds) at the same time :point_up_2:

+1. Would love to see parallel stages/tasks/steps within the same build.

To vote on this #feature-request please use the vote button at the top! :slight_smile: (related guide: About the Feature Requests category )

1 Like

Hi. Are there any updates on this feature?

Hi guys, we are definitely looking into implementing this in a way! But at the same time, we couldn’t provide an ETA just yet. Make sure to vote in the while! :slight_smile:


I removed “separate stacks for separate workflows” from the title because it’s already available.

Description of the feature request

Instead of having one entry for each triggered build when using “Bitrise start build” it would be nice if they where grouped into one build since they all depend on each other.

Use case / for what or how I would use it

Today lets say you have a “Bitrise start build” that triggers 3 separate builds “linting”, “unittest”, “uitests”.

You will then get something like this:
* status - some-branch-name - workflow
* Running - my-branch-name - trigger
* Running - my-branch-name - linting
* On hold - my-branch-name - unittest
* On hold - my-branch-name - uitest

I my mind it would be better to get something like this:
* status - some-branch-name - workflow
* Running - my-branch-name - trigger, linting, unittest, uitest
and when selecting you build you could get a new view that displays each separate build/workflow.

Maybe this is already possible, but I have at least not been able to find it :slight_smile:

1 Like

Hi @Torsph,

Thanks for the #feature-request!

This isn’t exactly possible, but at the moment I do not exactly see the upside of seeing running builds ‘grouped’ as opposed to separate, would you care to explain how would this help your use case? Would it simply be more convenient? :slight_smile:

Thanks for det reply! :+1:

In my mind it makes it easier to get a quick overview of whats going on. If you have multiple people working on multiple branches/PRs it makes the build list quite noisy. In my case you have 4 builds per trigger per PR. (React Native - js tests, ios tests, android tests and various other tools tests)

You can also get features as:

  • One trigger for multiple workflows
    – Where the trigger is triggering a group instead of separate workflows. A workflow today is basically a group to day (based on the yml file). It’s just not shown as one.
    – You can hide the complexity of “Bitrise Start Build” and “Bitrise wait for Build”
    – One status callback to GitHub when the build starts and finishes. Instead of manually doing that today if you are using the “Bitrise Start Build” step to trigger multiple builds without setting up “Bitrise wait for Build” step.
    – Possibly easier to integrate GitHub Checks since one check could just be one step in the group
  • Easily cancel all workflows in a group from the main listing
  • Easy see all builds triggered by a push to a PR.

I don’t know what ideas and plans you have for your system. Like making it really easy for the user or that it should be highly customisable.

Hope that makes it a bit more clear :slight_smile: If not just give me a ping and I will try to make my self understood :smile:


I don’t know this is a solution for this topic, but running bitrise command as background jobs could solve the problem?

set -ex
bitrise run common --config bitrise.yml
bitrise run ios --config bitrise.yml &
bitrise run android --config bitrise.yml &
1 Like

Neat idea! Not sure if in how many cases would that be sustainable solution, make sure to consider this method too: How to trigger multiple workflows at the same time

That may be a solution in some use cases but it has few drawbacks:

  • log items of 2 background process will be interleaved (so debugging may be harder)
  • all the workflows have to fit into single max build time

In our use case it works correctly without extending build time.

As @koral says debugging is really hard in this way, meaning that we have to arrange our workflow to debug problems. However, in general we don’t have to read debug logs if our build script works well.

Hope my information helps someone.

I’ve more or less gotten my pull requests to run 5 builds. But the process to do so was clumsy and unintuitive. My setup is something like:

  • PR triggers workflow1
  • end of workflow1 triggers workflow2
  • end of workflow4 triggers workflow5

This set up is somewhat rigid. If I wanted to inject workflowX somewhere in the middle there I’d have to go modify unrelated workflows. I also can’t arbitrarily run workflowY by itself, since it will trigger workflow(Y+1).

I think the original feature request:

and allow multiple workflows to be triggered by a single code push

… is still necessary.

In addition, if it’s not already stated, each of those workflows that were triggered should report back to the PR as separate statues on the PR so that I can see the build status from GitHub without having to click through to bitrise.


Is there any updates on this? :slight_smile:

Hi @Torsph!

No update yet, but we are looking into possible implementations :slight_smile:
Will get back once there has been any significant change! :wink:

Parallel Workflows for Testing Tutorials

1 Like