Useful for cordova repos, so I don’t have to configure two bitrise apps for one client
1 Like
Thanks for the feature request!
I think we had an idea which would make this possible and is probably simple enough to have a good user interface for:
- allow workflows to specify a stack
- and allow multiple workflows to be triggered by a single code push
Combining the two would make cross platform projects way easier to manage, as you could specify an Android specific workflow and an iOS specific one, using workflow chainging to not to define the common parts more than once, and then have a Trigger which would start both, on separate stacks.
I’d definitely 
this - @JoshPike don’t forget to vote on this feature request! 
Notes:
- I’d probably drop in a trigger map format revision too: Trigger map v2 - restructuring
- Commit/Pull Request status reporting should happen separately for the separate workflows, so that you can see on GitHub/… that e.g. the iOS build failed, but the Android one was successful
1 Like
Migrated from UserVoice:
Allow to run builds/tests in parallel.
It should work something like:
In bitrise.yml / in the Workflow Editor a “parallel” option could be defined, where each item in the list would define a build. E.g. if you add two items it’ll run two builds in parallel.
Each item could have it’s own list of Environment Variables, so that when the build starts those environments will be available for the build.
An example: split your Xcode tests into two Schemes, and define the two Schemes as Environment Variables in the parallel section. This would start two builds in parallel, one with the first Scheme and one with the second one.
One thing to note: there should be an option to trigger a new build for Deployment once ALL the tests pass. We don’t want to deploy in parallel, for each parallel test
(Although you might still want to deploy in parallel, e.g. if you create multiple configurations or you want to deploy to multiple services).
1 Like
It would be really great if we are able to select iOS stack (xcode version) based on workflows, instead of globally for the app.
This is useful when you develop swift applications and xcode releases break builds, so we could branch the updates and develop them in parallel.
The other aspect, for example just before release, we have a release branch, that we would like to keep on its existing stack and update our current development to the new stack.
It would be nice if Bitrise could schedule builds on specified stack.
use-case:
I’m developing my apps with stable IDE / build tool versions, but it would be great if i could prepare my project to the upcoming IDE / build tool version. So i would run my regular builds (triggered by git events) on stable stacks, but i would run scheduled builds in beta stack.
1 Like
Great idea!
Linking it to the API Feature Requests too, as this will most likely be part of that / will require the new public API changes:
I’d like to add my vote to this as well, specifically being able to run multiple workflows from the same trigger in parallel, and having them show up as separate checks in our GitHub PRs.
My use case is a project that will end up with 5+ unit testing projects over the coming months.
We could use multiple apps to do exactly this of course (and we might, if by the time we need this, it’s not supported yet), but proper support would be amazing for both convenience and maintainability. 
TL;DR: What Viktor said.
2 Likes
Thanks for the feedback @amulware - I agree and I think we’re slowly getting enough use cases & infos here to have a proper specification
It would be amazing to have this. At the moment our company has 4 Xcode schemes and chaining them makes the build take an absurd amount of time (times out). This is a must-have
1 Like
I definitely agree @dcvz - please vote on this feature request to bump its priority!
You could do a workaround with tagging the branch to trigger parallel builds.
triggers:
tag trigger: build-A-* triggers build_A
tag trigger: build-B-* triggers build_B
push trigger: release/* triggers build_All
workflow: build_All
- checkout
- add tag build-A-$BITRISE_BUILD_NUMBER
- add tag build-B-$BITRISE_BUILD_NUMBER
- call build_C
This actually triggers three builds at the same time. But all these tags are really ugly!
Would be really cool to just have a Plugin to trigger a build in parallel.
1 Like
Great workaround, thanks for sharing!
I definitely agree - don’t forget to vote on this Feature Requests!
My Xamarin App is normally built, tested and published using the Xamarin Stable stack.
I would like to create a scheduled builds of my Xamarin App once a week, after there are new VMs available, just to verify that my project still builds using the Xamarin Stable stack and also with Xamarin Beta to catch potential issues as early as possible.
I guess that this is another use case that this feature request could potentially provide?
2 Likes
Definitely, thanks for the use case! 
I’d also like a feature where I can trigger multiple builds. This would be very useful since we currently have four different schemes we want to be built on each pull request! If we want to have four builds on every push, we now have to wait 4 * x since the builds can’t be concurrent.
Hi, we have two apps being built from a single iOS codebase on the same branch. These two apps are currently two different workflows and we’ve identified two issues:
- rolling builds consider them to be the same and one is cancelled when the other is queued up manually.
- it’s not possible to configure triggers for multiple workflows for a single branch.
Now I assume we could merge the workflows but with this dual workflow config, builds would be available sooner so seem preferred. Also more scalable if we want to have more than two apps.
Comment migrated from: Two workflows triggered on the same branch
1 Like
I definitely +1 this feature request. It would be great to have one trigger for firing off multiple workflows. For example, a trigger could fire off a workflow for running unit tests and one for linting.
1 Like
Definitely planned @silverlogic6576 !
“Fun” fact, we already started to work on an early version of this (multi workflow trigger / allow multiple workflows in a trigger_map for a single item) but ultimately had to abort that solution completely as it had too many edge cases. The conclusion was that a single trigger should create a single “Build”, and parallel parts should be under the Build (like “stages” or “tasks”) in hierarcy (in practice e.g. have a single build page, but there separate “boxes” / logs for the separate “stages” / “tasks”), otherwise this change would break too many things (including e.g. the Rolling Build feature).
So, long story short, we’re committed to implement this feature but it’ll take more time than we originally expected. No ETA yet, it definitely won’t be available this year (in 2017), but definitely planned for next year (2018) “ASAP”
1 Like
The per-workflow stack selection feature is implemented! 
You can configure stack settings in the Workflow editor’s stack tab. You can change the app’s stack here, and for any workflow you can either set it to always be the same as the app’s stack (this is set by default), or to be a specific stack. More information here:
4 Likes
Are there any updates on supporting multiple builds per trigger? Or allowing duplicate trigger maps, which allows for effectively the same thing?