Frequently building APKs and uploading to Slack for testing? Follow this short guide to save much of your time!

Automation is to your time what compounding interest is to your money — Rory Vaden

Continuous Integration and Continuous Deployment is very important for Android development as it solves a lot of problems such as manually running unit and lint tests, pain of building multiple APK variants manually (such as production & staging/debug builds) and then sending them across to your QA team. With CI/CD, you can automate this and much more.

Goal

1. Automatically build all the app variants when I push code to a particular branch or create a new tag.
2. Optionally, run unit tests and lint checks.
3. Upload the generated APK(s) to Slack.

Get Started

GitLab Setup

Firstly, we add a Gitlab CI configuration file .gitlab-ci.yml inside our Android project root. You can easily do it through Gitlab. This file essentially contains all the instructions for our CI/CD pipeline. Read the documentation here if you are interested to know more about it.

Next, we need to create a configuration that will install everything needed to run the Android SDK, but since this is not optimal, we will use a fantastic Docker image by Jangrewe which is pre-configured for Android.

YML file for Gitlab CI

Before going further, let’s understand some of the basic GitLab CI keywords and the code in the .yml config file.

1. image: This tag is used to specify a Docker image to be used for execution. Gitlab runners will use this Docker image to run the pipeline.
2. cache: Caching the gradle folder significantly reduces the build time when generating multiple builds. The cache will be downloaded and extracted at the beginning and uploaded at the end of every job. ${CI_PROJECT_ID}is the unique project ID in Gitlab.
3. before_script: This is used to set up stuff before the actual work is started. In our case, we set GRADLE_USER_HOME to avoid using the complete path to gradle, and make the gradlew executable.
4. stages: These are globally defined levels that a pipeline run. It is used by jobs and run in the same order as their definition and each stage can contain different jobs. Note that when one job fails the rest of the jobs in other stages will not be executed.

Now, we define a job to build a debug APK and its contents are explained below.

1. stages: This signifies which stage the job belongs to.
2. only: Here, we define all the branch names for which the job will run. Including tags will run it whenever a new tag is pushed.
3. script: The shell script executed by the Gitlab Runner. It is the only mandatory keyword for a job to run.

• Firstly, we run the command to assemble the debug build
• After the build is generated, we use curl, a command line tool to transfer data.

Slack defines a pretty easy-to-use API for file upload. I would recommend going through the method documentation and find out all the different parameters which can be used. They also have a very useful API test tool.

Put the file name of generated APK (for example, app-debug.apk). If your gradle generates distinct build names as per the build version/type then use the find command with the initial characters of the file, as shown above.

TLDR — Simply paste these lines inside .gitlab-ci.yml.

Slack App Setup & Integration

Time to create a Slack app which will be used to upload the generated APK. Thankfully, it is pretty simple to do this part.

• Go to api.slack.com/apps and Click “Create an App” button. Enter a name for your app and click “Create App”.
• Click “OAuth & Permissions” menu item in the “Features” section.
• Scroll down to “Bot Token Scopes”, press “Add an OAuth Scope” button.
• In the opened dropdown search and select the “files:write” permission and click “Allow”
• Copy and save the OAuth Access Token somewhere.

• Add the App to your Slack channel through the Slack application and also save the channel ID of that channel.

• Now, go to your Project “Settings” in Gitlab, then “CI/CD”. Add the Auth Token and Slack Channel ID that you copied as variables here with the key same as the one used in .yml file