-
Notifications
You must be signed in to change notification settings - Fork 1
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Update CONTINUOUS_INTEGRATION.md (#423)
Co-authored-by: Gaëtan Muller <[email protected]>
- Loading branch information
Showing
1 changed file
with
21 additions
and
56 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,67 +1,32 @@ | ||
| # Continuous integration | ||
|
|
||
| The project provides support for continuous integration. | ||
|
|
||
| - The `Makefile` to initialize and execute [Danger](https://danger.systems/ruby/) locally. | ||
| - Gradle task to execute lint code using [Detekt](https://detekt.dev/). | ||
|
|
||
| We currently use TeamCity for continuous integration and GitHub for issue and pull request management. This document describes the steps required to fully integrate the tool suite with TeamCity and GitHub. | ||
|
|
||
| ## Required tools | ||
|
|
||
| The continuous integration server should have the following tools installed: | ||
|
|
||
| - [gem](https://rubygems.org) and [bundler](https://bundler.io). | ||
| - gradle | ||
|
|
||
| ## Continuous integration user | ||
|
|
||
| Our current workflow is based on pull requests, which TeamCity is able to automatically monitor with a dedicated [build feature](https://www.youtube.com/watch?v=4yFck9PvXI4). When a pull request is created TeamCity can automatically trigger various jobs which can post their result as pull request GitHub comments. | ||
|
|
||
| Proper integration with GitHub requires the use of a dedicated continuous integration user (a bot) with write access to the repository. We already have a dedicated [RTS devops](https://github.com/rts-devops) user, we therefore only need a few additional configuration steps: | ||
|
|
||
| 1. Ensure the bot has write access to the GitHub repository. | ||
| 2. Integration with GitHub requires the creation of a dedicated [personal access token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token) with minimal permissions. | ||
|
|
||
| Of course a proper SSH setup is also required so that repositories can be pulled by the continuous integration server. | ||
| The project provides support for continuous integration with GitHub Actions. | ||
|
|
||
| ## Code quality checks | ||
|
|
||
| To have TeamCity run code quality checks for GitHub pull requests and post the corresponding status back to GitHub: | ||
|
|
||
| 1. Create a TeamCity configuration called _Code quality_. | ||
| 2. Add a VCS _Trigger_ on `+:pull/*`. | ||
| 3. Add a _Command Line_ build step which simply executes `make danger`. | ||
| 4. Add a _Gradle_ build step which run Unit Tests with gradle task `clean testDebug`. | ||
| 5. Add a _Gradle_ build step witch run Instrumented Tests with gradle task `connectedAndroidTestDebug mergeAndroidReports`. | ||
| 6. Add a _Gradle_ build step witch build a Nightly from a pull request `pushDemoVersionToTeamcity assembleRelease appDistributionUploadRelease --groups=%env.NIGHTLY_GROUPS% --appId=%env.NIGHTLY_APP_ID%` and add the following environment variable to the configuration : | ||
| - `env.GITHUB_BRANCH_NAME` with value `%teamcity.pullRequest.source.branch%`. | ||
| - `env.IS_SNAPSHOT` with value `true`. | ||
| 7. Add a _Pull Requests_ build feature that monitor GitHub (requires a personal access token). | ||
| 8. Checks are performed by Danger, which requires a few [environment variables](https://danger.systems/guides/getting_started.html) to be properly set. Add the following three environment variable _Parameters_ to the configuration: | ||
| - `env.GITHUB_PULL_REQUEST_ID` with value `%teamcity.pullRequest.number%`. | ||
| - `env.GITHUB_REPO_SLUG` with value `SRGSSR/pillarbox-android`. | ||
| - `env.GITHUB_REPO_URL` with value `https://github.com/SRGSSR/pillarbox-android`. | ||
| 9. Add two _Agent Requirements_ ensuring that `env.GEM_HOME` and `env.ANDROID_HOME` exist. Check that some agents are compatible and assignable (if agents are configured manually you might need to explicitly allow the configuration to be run). | ||
|
|
||
| ## Deliveries | ||
|
|
||
| There is two kind of deliveries, libraries and a Demo application. | ||
| - The demo application is delivered threw _Firebase distribution_. Teamcity will publish a Nightly and a release version. The build agent needs to have a service google authentication installed. More information are available [here](https://firebase.google.com/docs/app-distribution/android/distribute-gradle?apptype=apk) | ||
| - The libraries are stored on Github packages on the repo. To publish new version of the libraries, | ||
| two variables need to be sets `env.USERNAME` and `env.GITHUB_TOKEN`. The Github token need to have the correct rights access for publishing on packages. | ||
| Every time a Pull Request is made or something is pushed to the `main` branch, the [`build.yml`](https://github.com/SRGSSR/pillarbox-android/blob/main/.github/workflows/build.yml) | ||
| workflow is triggered by GitHub Actions. It checks that the project builds on various platforms, runs code linters, dependencies check and finally | ||
| run tests. Result are posted directly in the Pull Request. | ||
|
|
||
| ### To have Teamcity building releases (Libraries and Demo application) | ||
| ## Libraries Deliveries | ||
|
|
||
| 1. Add a _Gradle_ build step which run task `clean pushVersionToTeamcity assembleRelease publish` | ||
| 2. Add a _Gradle_ build step which run task `appDistributionUploadRelease --groups=%env.RELEASE_GROUPS% --appId=%env.RELEASE_APP_ID%` | ||
| The libraries are delivered to GitHub Packages, the build is triggered when a git tag is published. | ||
| Not every tag will trigger a build. The tag have to follow a semantic release pattern. | ||
| Valid tags could be `1.2.30` or `5.4.3-beta01`. | ||
|
|
||
| ### To have teamcity building snapshots | ||
| ## Demo Deliveries | ||
|
|
||
| Add a _Gradle_ build step which run task `clean pushVersionToTeamcity assembleRelease publish` and add the following environment variable to the configuration : | ||
| - `env.IS_SNAPSHOT` with value `true`. | ||
| There are two kind of deliveries: | ||
| - Nightly builds are triggered manually or every day if there are some changes on `main`. | ||
| - Release builds are triggered when a libraries build is triggered. | ||
|
|
||
| ### To have teamcity building nightlies | ||
| ## Setup GitHub to run workflows | ||
|
|
||
| Add a _Gradle_ build step which run task `pushDemoVersionToTeamcity appDistributionUploadRelease --groups=%env.NIGHTLY_GROUPS% --appId=%env.NIGHTLY_APP_ID%` and add the following environment variable to the configuration : | ||
| - `env.IS_SNAPSHOT` with value `true`. | ||
| To build and publish the Demo, several variables needs to be setup as GitHub Actions secrets: | ||
| - `DEMO_KEY_ALIAS`: the key alias for the Gradle signature config. | ||
| - `DEMO_KEY_PASSWORD`: the key password for the Gradle signature config. | ||
| - `FIREBASE_CREDENTIAL_FILE_CONTENT`: the Firebase CLI credential file content. | ||
| - `NIGHTLY_APP_ID`: the Firebase project ID to publish the nightly. | ||
| - `NIGHTLY_GROUPS`: the Firebase testers group associated to the nightly demo. | ||
| - `RELEASE_APP_ID`: the Firebase project ID to publish the release. | ||
| - `RELEASE_GROUPS`: the Firebase testers group associated to the release demo. |