Android Matrix messenger application using the Matrix Rust Sdk and Jetpack Compose

Continuous integration strategy

Introduction

This document gives some information about how we take advantage of the continuous integration (CI).

We use GitHub Actions to configure and perform the CI.

We want:

The CI to detect as soon as possible any issue in the code
The CI to be fast - it's run on all the Pull Requests, and developers do not like to wait too long
The CI to be reliable - it should not fail randomly
The CI to generate artifacts which can be used by the team and the community
The CI to generate useful logs and reports, not too verbose, not too short
The developer to be able to run the CI locally - to help with this we have a script the can be run locally and which does more checks that just building and deploying the app.
The CI to be used as a common environment for the team: generate the screenshots image for the screenshot test, build the release build (unsigned)
The CI to run repeated tasks, like building the nightly builds, integrating data from external tools (translations, etc.)
The CI to upgrade our dependencies (Renovate)
The CI to do some issue triaging

The CI checks that:

The code is compiling, without any warnings, for all the app build types and variants and for the minimal app
The tests are passing
The code quality is good (detekt, ktlint, lint)
The code is running and smoke tests are passing (maestro)
The PullRequest itself is good (with danger)
Files that must be added with git-lfs are added with git-lfs

The CI reports:

The CI does not run R8 because it's too slow, and it breaks rule 2.

The drawback is that the nightly build can fail, as well as the release build.

Since the nightly build is failing, the team can detect the failure quite fast and react to it.

We limit the number of connected tests (tests under folder androidTest), because it often break rule 2 and 3.