Deploying Android Apps Using GitHub Actions

You want to release a build in the following scenarios:

1. You push a version tag to the repository.
2. You create a pull request targeting the master branch.

Let’s add the above conditions to trigger the workflow

Conditions to trigger a workflow are added under the on attribute.

Add the following code below the name attribute:

on:

Trigger Based on a Version Tag

A version tag name usually has the v prefix. For example, v1.10, v0.31, v/3.31 etc. You’ll use this convention to trigger the workflow when you push a version tag.

Add the following code under on in the workflow:

  push:
    tags:
      - 'v*'

Here, push specifies the event which triggers the workflow and tags specifies the configuration of the push event. v* is a regular expression that matches any string starting with v.

Commit your changes and push them to GitHub.

Create a new release tag and push it by running the following commands in the Terminal:

git tag v0.1 -a -m "Release v0.1"
git push origin master --follow-tags

This code creates a tag named v0.1 and pushes it with the commit message Release v0.1.

Once the push is complete, open the Actions tab. You’ll see that the workflow is running.

To verify that the workflow triggers only on the version tag, push an empty commit and check if that triggers the workflow. You can do so by running the following commands from the command line:

git commit --allow-empty -m "Empty commit"
git push origin master

In this code, --allow-empty lets you create an empty commit — that is, a commit without any changes.

Open the Actions tab in the repository and verify that the workflow hasn’t been triggered.

Trigger Based On A Pull Request to Master

A typical workflow among teams is to send a release APK to the QA team whenever a developer creates a PR to the master branch. Your next step is to make this happen automatically.

Add the following code to the on section of the workflow:

  pull_request:
    branches:
      - master

This code triggers the workflow when a pull that targets the master branch is created.

Commit and push the changes to GitHub, then verify the changes by creating a pull request from any branch to the master branch.

Preventing a Merge if Tests Fail

Before merging any code to master, you want to make sure that the new code builds correctly and that all tests pass. If any of these conditions fail, you want to block the pull request from merging. Branch protection helps you do this.

Go to GitHub and then navigate to Settings ▸ Branches on the repository.

Click Add branch protection rule in the Branch protection rules section.

First, you’ll have to set the Branch name pattern. Here, you can use a regular expression to apply the rule to multiple branches that follow a naming pattern. Since you want to protect the master branch, enter master in the text field.

Next, you’ll see a list of options, each with a checkbox. Check Require status checks to pass before merging. Since you want both the build job and the test jobs to pass, you have to check the unit_test and android_test tasks.

Finally, click Create at the bottom of the page. From now on, any pull request that fails these checks will be unable to merge.

Congratulations, you’ve completed the first part of your continuous delivery pipeline.