At innogy vbox we recently switched our Android test pipelines from a dedicated runner to Bitrise, mainly due to stability issues. We were running the Android tests in docker containers and while the setup theoretically allows for easy deployment on commodity hardware with just Docker installed, in effect it caused a lot of issues with unreliable tests.
Looking for alternatives, we quickly came across Bitrise. It offers GitLab integration and was a breeze to set up. It took less than 15 minutes to get our Android pipeline to run on Bitrise.
However, we also quickly came across one of the limitations of that integration: While you can trigger a workflow with your GitLab pipeline, there is no way run any part of it in parallel stages like you can with GitLab pipelines.
For instance, this is what our Android GitLab pipeline looks like:
All our test stages run in parallel and benefit for multiple runners being available to process it.
When integrating with Bitrise, these pipeline stages become steps in a Bitrise workflow, which will run sequentially.
The only way to break this up into steps is to create separate workflows for all the stages. But when you do so there is no way within Bitrise to create an overarching pipeline from it. They are just independent workflows.
And this is where bitrise-trigger comes into play. It is a glue project which allows you to use GitLab as the “pipeline controller”, triggering Bitrise workflows from its stages. These stages run independently on Bitrise – and will therefore benefit from concurrency, if that is part of your Bitrise plan.
While these stages are independent on Bitrise, everything is tied back together inside GitLab, with the pipeline view as you would expect.
See the the examples in the bitrise-trigger Readme and the project’s .gitlab-ci.yml file itself to see how this setup can help with your test infrastructure.