We currently have an android app with 2 flavors. Currently I run “gradle runner -> play publish” twice with each flavor. Not the most elegant solution but I couldn’t find a better way. However in the near future we are going support white labeled versions of our app, so the number of flavors will increase, meaning my current workflow isn’t very scalable.
Is it possible to have 1 Play Publish step that publishes each generated APK, matching the package name and publishing to the correct app on Google Play?
2 Likes
Hi @ChrisTitos,
The issue with just supplying lots of APKs for the Google Play Deploy step is how you’d map the “what’s new” texts, mapping.txt files etc for the separate set of APKs?
Just an idea but wouldn’t this work: have a single Gradle Runner step to generate all the flavors of the app, then have as many Google Play Deploy steps as you want to deploy and just set the APKs & other params.
Alternatively of course the sequence of Gradle+Deploy should also work, e.g.
- Gradle Runner 1
- Deploy 1
- Gradle Runner 2
- Deploy 2
- …
In yml mode you can quickly duplicate a sequence like this. Why do you think this would not scale?
One more option from the top of my head:
- have a single workflow where you define the Gradle Runner + Play Deploy step sequence but expect the variables as env vars
- then have multiple workflows which simply run this “template/utility” workflow after setting the env vars.
We do this with e.g. our Docker images where we build alpha & release versions for example, which do the exact same steps just with different params. See for example: https://github.com/bitrise-docker/bitrise-base/blob/cc57646a42bc3dd9970ca5ec97ff1f4e718fea1c/bitrise.yml#L155
Note for this: a workflow is not required to have any steps, it’s completely fine to have a workflow which just sets some env vars then runs another workflow (via before_run or after_run).
If you’d have any questions just let us know! 
