Skip to content
This repository has been archived by the owner on Jun 17, 2024. It is now read-only.

Latest commit

 

History

History
121 lines (77 loc) · 5.4 KB

automation.md

File metadata and controls

121 lines (77 loc) · 5.4 KB

Automation and continuous integration systems

Our Android projects share a similar automation model:

  • Taskcluster is our primary CI: we use it for as much automation as possible, including our core builds and releases, because it's a flexible first party service we can rely on.
  • GitHub Actions is secondary: it runs some regular tasks or a subset of tests for pull requests.

Taskcluster

Taskcluster is a generic task execution framework developed and used by Mozilla to automate continuous integration and release processes.

We currently use Taskcluster to:

  • Build, test and run code tools for all master commits and pull requests (including contributor PRs). See Code quality tools for additional information.
  • Build (unsigned) release builds whenever a release is created on GitHub
  • Automatically import new translations from the L10N repository.

To see a Taskcluster configuration for your project, see <project-root>/.taskcluster.yml (here's an example in focus-android).

Taskcluster runs using docker: see our docker guide for more information.

GitHub Actions

GitHub Actions is GitHub's own CI/CD service.

We currently use GitHub Actions to:

  • Build, test and run code tools for pull requests (including contributor PRs).
  • Automatically update dependencies & synchronize localization files
  • Automatically adding additional labels to new issues

To see the GitHub Actions configuration for your project, see <project-root>/.github/workflows (here's an example in Fenix).

You can find the workflows and builds logs under the "Actions" tab of each project.

Code quality tools

For Kotlin only projects, run these tools:

For projects that also include Java, add these tools:

  • checkstyle
  • findbugs
  • PMD

To see what tools are currently run in automation for your project, see the project's <project-root>/.taskcluster.yml (here's an example in focus-android).

Third-party services

Codecov

Codecov evaluates the code coverage reports generated by our build and tracks the coverage over time. It warns when merging pull requests would lead to dropping the coverage below a specified threshold.

Automation tasks

Pull request pipeline

Release pipeline

Eventually we want to automate the whole release process pipeline in order to have "one click" releases without much workload for the engineering team.

✅ Active: Release builds

Whenever a release is created on GitHub, we build releases versions of the project on taskcluster (example: focus-android configuration).

✅ Active: Signing

Signing requires access to Mozilla's signing certificates. In addition to that a signing task needs to be able to validate the origin of the APK ("Can I trust the task that built the APK?") to avoid signing random tasks.

✅ Active: Upload to archive.mozilla.org

Every release is published on archive.mozilla.org. Nightly builds go to https://archive.mozilla.org/pub/fenix/nightly/ and https://archive.mozilla.org/pub/focus/nightly/. Release builds are uploaded to https://archive.mozilla.org/pub/fenix/releases/ and https://archive.mozilla.org/pub/focus/releases/.

✅ Active: Publish

Finally we want to publish a release build on Google Play

Like other scriptworker instances, we can use the existing instance. The current implementation is fennec-specific. We have to add support there too. pushapk_scriptworker mainly delegates checks and uploads to mozapkpublisher. That tool needs Focus support. Working on mozapkpublisher doesn't require any Taskcluster knowledge.

Nightly (Alpha) pipeline

TODO: explain the current process

Maintenance tasks

✅ Active: String import

Every day at 12:00 UTC we run a script that imports the latest translations from the L10N repository and creates a pull request for the import if there are new strings. Eventually this import can be merged automatically. For now we want to review those changes manually to validate that the task is running as intended.

We hope to improve this process soon.