From 9ac894e0b288454f3e927743520fc9f234fe54a3 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Joaquim=20St=C3=A4hli?= Date: Mon, 29 Jan 2024 10:54:55 +0100 Subject: [PATCH] Update CONTINUOUS_INTEGRATION.md (#423) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Gaëtan Muller --- docs/CONTINUOUS_INTEGRATION.md | 77 ++++++++++------------------------ 1 file changed, 21 insertions(+), 56 deletions(-) diff --git a/docs/CONTINUOUS_INTEGRATION.md b/docs/CONTINUOUS_INTEGRATION.md index 74f8409b6..eef63b091 100644 --- a/docs/CONTINUOUS_INTEGRATION.md +++ b/docs/CONTINUOUS_INTEGRATION.md @@ -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.