CI in the context of Radicle

What is CI?

CI is short for continuous integration. In its pure form it means the practice of integrating changes to a code base frequently to avoid merge conflicts. Merge conflicts can be a lot of work to resolve, and resolving a big conflict can result in errors. This happens in large development teams, including in large open source projects.

In the context of Radicle, CI is tooling that reacts to changes in a Radicle repository and builds the software and runs any commands specified in the repository. This can be a powerful tool that can be used for many things. Mostly it’s used to build software and run its automated test suite. It can also be used to, say, automate updates to a web site, or build binaries for release versions of software for distribution to users of the software.

Example

As a concrete example, the repository for the Radicle CI broker has the following file in its repository to tell Radicle CI what to do (this is an abbreviated version for simpliciy, see .radicle/ambient.yaml for the full version):

pre_plan:
  - action: cargo_fetch
plan:
  - action: shell
    shell: |
      make

In short, this tells the CI system to download any Rust crates that are dependencies, then run make. The Makefile then specifies all the building and testing that needs to happen. (Developers would run make on their develpment system to do what CI does.)

Why use CI?

A CI system does things a developer could do by hand. In principle, a CI system is never needed, when we can assume that software developers are consistently diligent and never make errors.

Because software is developed by error prone entities that make mistakes, a CI system is useful for various reasons:

• consistency: a deterministic system is less likely to make mistakes, or forget some steps
• tedium: letting a machine do the boring parts lets a human enjoy life more, such as taking a break while CI runs
• trust: a CI system is typically easier to secure than an individual developer’s laptop, which means any release artifacts are less likely to be infected by malware
• consitent variety: an individual developer typically only uses one computer environment at a time; a CI system can do things in a wide variety of environements, with different hardware, different versions of software, etc; this in turn can expose problems before they are merged

There’s more reasons, and this is not meant to be exhaustive. They can all be summarized as “consistent quality”.

Distributed CI

Radicle is a distributed system and it makes sense for its CI support to enable distribued CI. By that we means that every Radicle node can choose to run CI for its repositories. Each node admin decides for themselves for what repositories it runs CI and how. On the other hand, each project decides for themselves what CI nodes they trust.

Distributed CI for Radicle does not mean parts of the same CI run execute on different hosts. That would also be an interesting thing to have, but a much harder problem to solve.