Automated Release for Android Using GitHub Actions

Whenever we build an application and push the code to GitHub, it is obvious that we might want to create a release so that it can be used by people without building the project in their local environment. This release can be an APK for an Android Project or a hosted website for Web Development projects. We are going to talk about the Android project here. So all of this can be accomplished by using the Releases section, where we generate a new release every time we make a productive modification to the code by setting the Release Name, Release Tag, and appropriate description for each release.

Repeating the same tasks can be stressful and monotonous at times. So here comes the feature of building automated releases using GitHub Actions. Every time we have a pull request that gets merged, or if the maintainer of the code pushes some changes to the codebase, the process of building the code, creation of the APK, and releasing it gets triggered. As a result, the process of manually creating the release is freed up. In order to get started, I would suggest having a basic understanding of how to build CI pipelines using GitHub Actions. Create a .yml file named build-and-release.yml in .github/workflows directory under the project’s root directory. Start writing the code in that file.

name: Build and Release

on:
 push:
   branches:
     - master
   tags:
     - "v*"

jobs:
 apk:
   name: Generate APK
   runs-on: ubuntu-latest
   steps:
     - name: Checkout
       uses: actions/checkout@v2.4.0
     - name: Setup JDK
       uses: actions/setup-java@v2.5.0
       with:
         distribution: temurin
         java-version: "11"
     - name: Set execution flag for gradlew
       run: chmod +x gradlew
     - name: Build APK
       run: bash ./gradlew assembleDebug --stacktrace
     - name: Upload APK
       uses: actions/upload-artifact@v1
       with:
         name: apk
         path: app/build/outputs/apk/debug/app-debug.apk

 release:
   name: Release APK
   needs: apk
   runs-on: ubuntu-latest
   steps:
     - name: Download APK from build
       uses: actions/download-artifact@v1
       with:
         name: apk
     - name: Create Release
       id: create_release
       uses: actions/create-release@v1
       env:
         GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
       with:
         tag_name: ${{ github.run_number }}
         release_name: ${{ github.event.repository.name }} v${{ github.run_number }}
     - name: Upload Release APK
       id: upload_release_asset
       uses: actions/upload-release-asset@v1.0.1
       env:
         GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
       with:
         upload_url: ${{ steps.create_release.outputs.upload_url }}
         asset_path: apk/app-debug.apk
         asset_name: ${{ github.event.repository.name }}.apk
         asset_content_type: application/zip

name is the full name of the workflow, which will be displayed in the list of workflows under the actions tab. on defines when will the workflow trigger. Here we are willing to trigger the workflow as soon as we push the code to the master branch or a new tag with v as a prefix is specified. As we know every workflow has some jobs that are to be executed as the flow is triggered, hence here we have made two jobs with titles as apk and release. 

In the first job we specify the name as Generate APK, the first step is to set up the environment and it is specified by runs-on. Here we are using GitHub hosted ubuntu-latest. Following it, we have specified the checkout actions that will check out the repository under $GITHUB_WORKSPACE, so that the workflow we are writing can access it. Then we set up JDK along with build apk. As soon as this is done, we are fetching the apk from the directory app/build/outputs/apk/debug/app-debug.apk and uploading it to the artifacts sections of GitHub. 

All of this summarises our initial task of building the apk, retrieving it from the directory where it was generated, and uploading it to the artifacts section. Now we are going to create a release using this apk in the next job i.e release with the name Release APK. 

First of all, we specify that for this job to be executed, the job with title apk has to be completed, which is done by writing needs: apk. As we did in the previous job, here also we set the environment as ubuntu-latest. We uploaded the apk to the artifacts section in the previous job, so we now download that apk and start creating a release.

To create a release, this job needs to have the GITHUB_TOKEN provided by the virtual environment and can be accessed by simply writing ${{ secrets.GITHUB_TOKEN }}. Now for every release created, there must be a tag name and release name for that particular release. So to make it dynamic, we specify the tag_name as run number i.e. ${{ github.run_number }} and release_name as the repository name along with run number i.e. ${{ github.event.repository.name }} v${{ github.run_number }}. 

Now the release has been created and we want to upload release apk. So again for doing this we need to provide GITHUB_TOKEN to the job. We define the upload_url that is the URL for uploading the asset as ${{ steps.create_release.outputs.upload_url }}, asset_path from where the apk will be extracted as apk/app-debug.apk, asset_name for setting the name of apk as ${{ github.event.repository.name }}.apk and asset_content as application/zip.

When done with writing the workflow, commit the changes and go to the Actions tab, you’ll see a workflow running.

When both the jobs i.e. Generate APK and Release APK shows green check, go to Code and on the right side in the Releases section, you will see a release published with the name as the repository name happened with v1.

All this concludes our task of writing a workflow in which every time some changes are pushed to the master branch, it gets triggered which ultimately creates a release and uploads it to the Releases section of the GitHub Repository. As a result, we are no longer required to create the release manually.