In the previous post of this series, we showed how to use Fastlane to create an automated way to build, package, and upload your Android app to Play Console's Internal test channel locally. In this post, we will show how to use that same script but running it on GitHub Actions to create a CI/CD system that gets triggered when you push to a specific branch.
As noted in the previous post, we aim to make this automated way as CI/CD-agnostic as possible. Therefore, even if you are not using GitHub Actions, I believe that this will be easy to adapt to the platform of your choice.
Set the variables
In the last post, we created a script that sets the necessary environment variables and then runs the
fastlane deploy command. So the first thing here is to set the environment variables in the GitHub Actions runner.
In your GitHub project, head to the
Settings tab ->
Secrets and variables ->
Actions. Note that the secrets that you are setting will not be readable once you set them. You would be able to update their value, but not see the existing value. So make sure that you store the values of these secrets safely somewhere else. From there you would need to set these secrets:
The 2 variables with the asterisk are not string values, but files that need to be stored here somehow. We will use Base64 encoding to store these files as strings.
To get the base64 value of those files, open your terminal in your Unix-based OS (I am sure there's an equivalent way on Windows), and run:
base64 -i /path/to/the/file | pbcopy
This will copy the base64 value of the file into the clipboard and will be ready to be pasted as a value in GitHub secrets.
GitHub Actions script
Now we have everything we need to create our CI/CD. Don't be intimidated by the size of this script. If you look carefully it's self-explanatory. Long story short, we are setting up Fastlane, decoding from base64 back to binary the 2 files we need, and then running the same
fastlane deploy command to do the build+package+upload magic. A reminder that the
fastlane/ directory described in the previous post needs to be committed for this to work.
This gets triggered every time something is pushed on the branch called
staging. But you can change this condition depending on your team's procedures.
That's it! You now have a CI/CD system in place that deploys every time you commit to a certain branch. In addition, if something breaks, it's relatively easy to debug since literally all the GitHub Actions runner is doing is running the
fastlane deploy command. So just figure out what is broken locally, and (hopefully) as soon as you commit the issue will be gone.
In this series: