| Serge Bazanski | 5aa494f | 2021-05-18 18:57:10 +0200 | [diff] [blame] | 1 | Monogon CI |
| 2 | ========== |
| 3 | |
| 4 | Monogon has a work-in-progress continuous integration / testing pipeline. |
| 5 | Because of historical reasons, some parts of this pipeline are defined in a |
| 6 | separate non-public repository that is managed by Monogon Labs. |
| 7 | |
| 8 | In the long term, the entire infrastructure code relating to this will become |
| 9 | public and part of the Monogon repository. In the meantime, this document |
| 10 | should serve as a public reference that explains how that part works and how it |
| 11 | integrates with `//build/ci/...` and the project as a whole. |
| 12 | |
| 13 | Builder Image & Container |
| 14 | ------------------------- |
| 15 | |
| 16 | `//build/ci/Dockerfile` describes a 'builder image'. This image contains a |
| 17 | stable, Fedora-based build environment in which all Monogon components should |
| 18 | be built. It has currently two uses: |
| 19 | |
| 20 | 1. The build scripts at |
| 21 | `//scripts/{create_container.sh,destroy_container.sh,/bin/bazel}`. These are |
| 22 | used by developers to run Bazel against a controlled environment to develop |
| 23 | Monogon code. The `create_container.sh` script builds the Builder image and |
| 24 | starts a Builder container. The `bin/bazel` wrapper script launches Bazel in |
| 25 | it. The `destroy_container.sh` script cleans everything up. |
| 26 | |
| 27 | 2. The Jenkins based CI uses the Builder image as a base to run Jenkins agents. |
| 28 | A Monogon Labs developer runs `//build/ci/build_ci_image`, which builds the |
| 29 | Builder Image and pushes it to a container registry. Then, in another |
| 30 | repository, that image is used as a base to overlay a Jenkins agent on top, |
| 31 | and then used to run all Jenkins actions. |
| 32 | |
| 33 | As Monogon evolves and gets better build hermeticity using Bazel toolchains, |
| 34 | the need for a Builder image should subdue. Meanwhile, using the same image |
| 35 | ensures that we have the maximum possible reproducibility of builds across |
| 36 | development and CI machines, and gets us a base level of build hermeticity and |
| 37 | reproducibility. |
| 38 | |
| 39 | CI usage |
| 40 | -------- |
| 41 | |
| 42 | When a change on https://review.monogon.dev/ gets opened, it needs to either |
| 43 | be owned by a 'trusted user', or be vouched by one. This is because our current |
| 44 | CI setup is not designed to protect against malicious changes that might |
| 45 | attempt to take over the CI system, or change the CI scripts themselves to skip |
| 46 | tests. |
| 47 | |
| 48 | Currently, all Monogon Labs employees (thus, the core Monogon development team) |
| 49 | are marked as 'trusted users'. There is no formal process for community |
| 50 | contributors to become part of this group, but we are more than happy to |
| 51 | formalize such a process when needed, or appoint active community contributors |
| 52 | to this group. Ideally, though, the CI system should be rebuilt to allow any |
| 53 | external contributor to run CI in a secure and sandboxed fashion. |
| 54 | |
| 55 | CI implementation |
| 56 | ----------------- |
| 57 | |
| 58 | The CI system is currently made of a Jenkins instance running on |
| 59 | https://jenkins.monogon.dev/. It runs against open changes that have the |
| 60 | Allow-Run-CI label evaluated to 'ok' Gerrit Prolog rules, and executes the |
| 61 | `//build/ci/jenkins-presubmit.groovy` script on them. |
| 62 | |
| 63 | Currently, the Jenkins instance is not publicly available, and thus CI logs are |
| 64 | not publicly available either. This will be fixed very soon. |