KernelCI Architecture

The first thing worth noting here is that there are a number of main parts of the overall KernelCI architecture:

Maestro

The middle left box of this picture shows Maestro. While Maestro is only one software system, architecturally its flow has 2 parts: (1) triggering builds and list of tests to run on each platform and (2) driving such tests.

Maestro has a pipeline-based design and an API that allow other systems and tools to interact with it to subscribe to events (such as new build/test triggers) or send patches to be tested by the KernelCI infrastructure.

kci-dev

kci-dev is a stand-alone tool for Linux Kernel developers and maintainers to interact with KernelCI. There is full documentation available at kci.dev and a PyPI package. Source code is available on GitHub.

Web Dashboard

A new web dashboard has been developed to allow users to easily visualise results from KernelCI testing. Development, issues and feature requests are all being tracked on GitHub.

KCIDB

CI systems producing their own kernel builds and running their own tests can submit results to KCIDB, which is a BigQuery database to provide a unified kernel test reporting mechanism. Please take a look at this blog post for a comprehensive description: Introducing Common Reporting.

CI Ecosystem

Any CI/test system can be part of KernelCI by receiving triggers from Maestro and submitting their data to KCIDB. Receiving triggers is an optional for CI/test system, as many have their own trigger configuration already.