Great question @MattNewberry, thanks for asking this here, I’d be interested to hear how others solve this as well!
Just a couple of notes:
If you need more than 45 mins for a single build and you have a subscription with at least 2 concurrencies, feel free to ping us and we can bump the build limit to 90 mins, but of course faster test results are way better.
Ohh, definitely! Unfortunately this is not a “just a few clicks” operation, but it definitely can be done - I shared more info about something like this here, where the question was how you could trigger a build for one repository when a different one changes, which requires the same “API workflow” solution you mentioned: Can a bitrise “build” be triggered from more than one repository?
If you have any sample config and any stats how much that speeds up things, please let us know, we’d definitely be interested in this! (bluepill is on our list to explore and see if we could integrate into an existing step, or create a new step, if it worth it)
Sounds absolutely fantastic! We have plans to make this easier too, by allowing you to define which things to run in parallel right in your build config. We have the basic sketches about the “design”, but we’re still discussing the details, how it could be compatible with the current Bitrise yml format and bitrise.io in general, etc. Hopefully we can work on the new “v2” config this year, but first we have to finish a couple of other things.
One more thing, we’re experimenting with new, more powerful build machine configs, which can speed up your builds if the build is CPU and/or RAM intensive. These new configs should be available soon, but will cost more, unfortunately.
If you’re interested in joining the private beta, we can give you a free trial to see if it helps to speed up your builds (might not, depends on the project and whether it can utilize the faster CPU and additional available RAM).