Building a CI-CD Pipeline for an Android project

An Android project is an ideal candidate for CI/CD Solutions and could leverage the full power of cloud. Google provides the complete android build environment as a command line tool and therefore configuring it with a CI/CD script is not too difficult.

For this article, We will continue to explore Github Actions

Q. What can we do with a CI/CD workflow?

We can make a script that will command the CI/CD server to run a set of actions on certain events, like a git push to a particular branch, or when a PR is raised from one git branch to another. We can also configure the script to be started manually on a button press and not on any event

Q. But what task we can create for an Android Project?

Our script could:

Run lint checks on the project code.
Run Static Code Analysers on the project code.
Run Unit Tests , Instrumental Tests on the project code.
Generate and Publish Reports of actions.
Compile the project code to ensure the proper working of code.
Generate Artifacts ( .AAR , .APK files)
Publish the Artifacts to their respective marketplace, like mavenCentral for library builds or Play Store for APK builds.
Send notifications to Slack
and much more.

Q. But why would I want to do all these tasks?

Let us create a script that does some of the above tasks while understanding the importance of each of these steps

create a folder .github/workflows in your project and add the following file:

A github action running for a particular commit pushed to branch

Cool, so we build a basic action that is going to run some steps on every push to master branch . And these steps include setting up an environment, building code and uploading results.

Why should we do that? A nice use case would be for an open source project where anyone could raise a PR that includes changes to original code. as a repository maintainer, you might not have time to checkout their PR’s code, build it, and ensure that its not breaking the old code. So such Pipeline could come handy.

Let’s add 2 more fairly obvious actions lint checks and unit tests

Just before the step to generate AAR, we can add these 2 more steps

...
- name: Check lint        
if: always()        
run: ./gradlew lint- name: Run Unit Tests
if: always()        
run: ./gradlew testDebugUnitTest- name: Generate AAR and APK files
...

Lint checks are useful because they help see warnings that are raised by android studio during the building. these are not of immediate concern, but they could possibly become errors in future based on the severity.

Similarly Unit Tests passing on a code is a very important check to ensure that newly added code does not break the previous logics.

These steps in the action will generate beautiful reports and we should upload them too via the artifact action available. you can check the dogFinder repo to get the latest up to date action script for these tasks.

Until now, we did not had to make any changes in our original code to get the action to work. This was because the environment we set up already provided us those features. We can even run those ./gradlew xyz tasks from our android studio console and those will work correctly

However features like publishing to mavenCentral, Google Play console or running Static code analysis tools require a project level setup thus here the flow will be:

We will add some libraries in our code to enable support for Static code analyzers.
These libraries will register actions in Gradle which we can run via command line .
During setup of our code on the cloud , those libraries will also get initiated and register their actions on the gradle in cloud
Then CI/CD will be able to run those actions too!

We will be using detekt and checkstyle to most common static code analysers for Kotlin and Java code respectively.

in your action script, add this: