Android CI/CD part 2: Building and pushing to Play Store in GitHub Actions

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:

• GPLAY_SERVICE_ACCOUNT_KEY *
• STAGING_KEYSTORE_FILE *
• STAGING_KEYSTORE_PASSWORD
• STAGING_KEY_ALIAS
• STAGING_KEY_PASSWORD
• STAGING_PACKAGE_NAME

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.

name: Staging Deploy

on:
  push:
    branches: [ "staging" ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2

      - name: Set up Ruby
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: 2.7.2
          bundler-cache: true

      - name: Create Google Play Service Account Key file
        uses: timheuer/base64-to-file@v1
        id: service_account_json_file
        with:
          fileName: "serviceAccount.json"
          encodedString: ${{ secrets.GPLAY_SERVICE_ACCOUNT_KEY }}

      - name: Create Keystore file
        uses: timheuer/base64-to-file@v1
        id: android_keystore
        with:
          fileName: "android_keystore.keystore"
          encodedString: ${{ secrets.STAGING_KEYSTORE_FILE }}

      - name: Deploy Android release
        run: bundle exec fastlane android deploy
        env:
          STAGING_PACKAGE_NAME: ${{ secrets.STAGING_PACKAGE_NAME }}
          STAGING_KEYSTORE_FILE: ${{ steps.android_keystore.outputs.filePath }}
          STAGING_KEYSTORE_PASSWORD: ${{ secrets.STAGING_KEYSTORE_PASSWORD }}
          STAGING_KEY_ALIAS: ${{ secrets.STAGING_KEY_ALIAS}}
          STAGING_KEY_PASSWORD: ${{ secrets.STAGING_KEY_PASSWORD }}
          GPLAY_SERVICE_ACCOUNT_KEY: ${{ steps.service_account_json_file.outputs.filePath }}

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.

Happy coding!

In this series: