Benoit Marty
1 year ago
1 changed files with 69 additions and 0 deletions
@ -0,0 +1,69 @@ |
|||||||
|
# Continuous integration strategy |
||||||
|
|
||||||
|
<!--- TOC --> |
||||||
|
|
||||||
|
* [Introduction](#introduction) |
||||||
|
* [CI tools](#ci-tools) |
||||||
|
* [Rules](#rules) |
||||||
|
* [What is the CI checking](#what-is-the-ci-checking) |
||||||
|
* [What is the CI reporting](#what-is-the-ci-reporting) |
||||||
|
* [Current choices](#current-choices) |
||||||
|
* [R8 task](#r8-task) |
||||||
|
* [Android test (connected test)](#android-test-connected-test) |
||||||
|
|
||||||
|
<!--- END --> |
||||||
|
|
||||||
|
## Introduction |
||||||
|
|
||||||
|
This document gives some information about how we take advantage of the continuous integration (CI). |
||||||
|
|
||||||
|
## CI tools |
||||||
|
|
||||||
|
We use GitHub Actions to configure and perform the CI. |
||||||
|
|
||||||
|
## Rules |
||||||
|
|
||||||
|
We want: |
||||||
|
|
||||||
|
1. The CI to detect as soon as possible any issue in the code |
||||||
|
2. The CI to be fast - it's run on all the Pull Requests, and developers do not like to wait too long |
||||||
|
3. The CI to be reliable - it should not fail randomly |
||||||
|
4. The CI to generate artifacts which can be used by the team and the community |
||||||
|
5. The CI to generate useful logs and reports, not too verbose, not too short |
||||||
|
6. The developer to be able to run the CI locally - to help with this we have [a script](../tools/check/check_code_quality.sh) the can be run locally and which does more checks that just building and deploying the app. |
||||||
|
7. 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) |
||||||
|
8. The CI to run repeated tasks, like building the nightly builds, integrating data from external tools (translations, etc.) |
||||||
|
9. The CI to upgrade our dependencies (Renovate) |
||||||
|
10. The CI to do some issue triaging |
||||||
|
|
||||||
|
## What is the CI checking |
||||||
|
|
||||||
|
The CI checks that: |
||||||
|
|
||||||
|
1. The code is compiling, without any warnings, for all the app build types and variants and for the minimal app |
||||||
|
2. The tests are passing |
||||||
|
3. The code quality is good (detekt, ktlint, lint) |
||||||
|
4. The code is running and smoke tests are passing (maestro) |
||||||
|
5. The PullRequest itself is good (with danger) |
||||||
|
6. Files that must be added with git-lfs are added with git-lfs |
||||||
|
|
||||||
|
## What is the CI reporting |
||||||
|
|
||||||
|
The CI reports: |
||||||
|
|
||||||
|
1. Code coverage reports |
||||||
|
2. Sonar reports |
||||||
|
|
||||||
|
## Current choices |
||||||
|
|
||||||
|
### R8 task |
||||||
|
|
||||||
|
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. |
||||||
|
|
||||||
|
### Android test (connected test) |
||||||
|
|
||||||
|
We limit the number of connected tests (tests under folder `androidTest`), because it often break rule 2 and 3. |
Loading…
Reference in new issue