KernelCI maintainers

There are several types of maintainer roles with different responsibilities:

software maintainers
in charge of the KernelCI software components
service maintainers
in charge of the KernelCI hosted services
feature maintainers
in charge of features that span across the whole KernelCI stack
instance maintainers
in charge of a particular KernelCI instance (production, staging…)
channel maintainers
in charge of the communication channels used by KernelCI

Most maintainers are members of the TSC but additional people can be involved too.

Software Maintainers

At least one maintainer is assigned to each software component. The work involves reviewing pull requests on GitHUb, triaging issue, updating GitHub settings and facilitating the development workflow. Having “deputy” maintainers whenever possible also helps with the continuity of the project when regular maintainers are not available..

In addition to maintainers for each project, some GitHub administrators are available to make configuration changes at the organisation level. This includes managing teams, permissions for each project, adding / moving / removing projects, configurating workboards and updating any other general settings.

Core tools

The core tools provide the command line utilities and the kernelci Python package used to implement a KerneLCI pipeline and run individual steps by hand (building kernels, scheduling tests…).

  • Repository: kernelci-core
  • Maintainers: mgalka, nuclearcat
  • Deputy: alicef


The new KernelCI API is a work-in-progress replacement for the backend currently used in production. It also features a Pub/Sub interface to coordinate the pipeline services in a modular fashion.


The KernelCI pipeline is also a work-in-progress based on the new API and its Pub/Sub interface. This is essentially to replace the Jenkins pipeline currently used in production.


KCIDB provides a set of tools to submit kernel test data to a common database.

Backend (deprecated)

The KernelCI backend provides a web API to send build and test results and let the frontend dashboard retrieve. It also generates email reports, tracks regressions and triggers automated bisections. The new API will eventually replace it.

Frontend (deprecated)

The KernelCI frontend provides a dynamic web dashboard showing the data available from the backend. A new workboard is currently being developed to replace it and include data from KCIDB.

lava-docker (interim)

Note: The lava-docker repository is about to join the LAVA GitLab organisation. See the email discussion for more details.

This project is to Simplify the installation and maintenance of a LAVA lab using Docker containers.

  • Repository: lava-docker
  • Maintainers: alicef, montjoie

Service maintainers

Services hosted by KernelCI all need someone to look after them and ensure they stay online and available. This is essentially sysadmin work with some code maintannce too depending on the cases.

Jenkins (deprecated)

The current KernelCI pipeline is using Jenkins. While this is about to be replaced with the new pipeline and API, the purpose remains essentially the same: orchestrating the builds and tests on

  • Maintainers: broonie, mgalka, nuclearcat
  • Components: kernelci-jenkins
  • Resources: Azure, GCE


Several Kubernetes clusters are used by KernelCI, to build kernels and run platform-independent tasks or kernel tests in containers (static analysis, KUnit, QEMU…).

  • Maintainers: khilman, broonie
  • Resources: Azure, GCE

VM Servers

A number of virtual machine servers are being used to host various services such as Jenkins and the web frontend. They are currently all managed in Azure, but this may evolve over time. They require sysadmin maintenance, monitoring tools, backups…

  • Maintainers: mgalka, nuclearcat
  • Resources: Azure (VMs, Mongo DB)


KCIDB uses BigQuery as a database engine. This requires setting up tokens and managing the associated Cloud resources.

  • Maintainers: spbnick, khilman
  • Resources: BigQuery, GCE


KCIDB uses a Grafana instance as a prototype web dashboard. Additional instances may be set up for other use-cases, such as showing statistics about the KernelCI project in general.

  • Maintainers: spbnick
  • Resources: VM Servers

Docker Hub

All the Docker images used by KernelCI are pushed to the Docker Hub. This requires some maintenance in particular to keep an eye on resource usage and to adjust permissions.

  • Maintainers: gtucker, mgalka

Feature maintainers

Some advanced KernelCI features involve coordination between multiple software components and services. They also require dedicated maintainers to ensure they keep running as intended.

Native tests

Tests orchestrated on are called the native KernelCI tests, unlike tests running in independent CI systems which provide results directly to KCIDB. This covers integration with test labs, rootfs images, pipeline configuration… anything related to running those tests and getting their results into the database.

Native builds

Just like tests, kernel builds orchestrated on are called the native KernelCI builds.


For every test regression detected, an automated bisection is run whenever possible. This involves building kernels, running tests and checking their results in a coordinated way to then send an email report when the bisection succeeds.

Instance maintainers

As there are several KernelCI instances, it’s necessary to have people dedicated to each of them.

Production instance

The KernelCI components and services need to be regularly updated on the production instance with the latest code and configuration changes. This includes typically enabling coverage for new kernel branches or running new tests, as well as updating rootfs and Docker images with the latest versions of all the packages being used.

It is currently done once a week on average, although deployment may become gradually more continuous as services start to get hosted in the Cloud and run in Docker containers.

Staging instance

All the incoming pull requests are merged into temporary integration branches and deployed on [](] for testing. This is explained in greater detail in the Staging section.

ChromeOS instance

The Chrome OS KernelCI instance is dedicated to building specific kernels and running Chrome OS tests on Chromebooks. This is very close to the code used in production but has continuous deployment like the staging one, including open pull requests for the chromeos branches. These branches need to be regularly rebased with any extra patches that are not merged upstream, typically after each production update.

CIP instance

The CIP instance is dedicated to building CIP specific kernels with CIP configurations. Currently the CIP KernelCI code is in production.

Channel Maintainers

As with any open-source project, ensuring communication between all the contributors, users and maintainers is essential. Several channels are available for KernelCI and each of them requires some maintenance too.


This is about keeping the #kernelci IRC channel on updated and managing automated notifications sent to it (monitoring services, GitHub and Jenkins integration…)

  • Maintainers: montjoie

All the KernelCI mailing lists are managed via Maintaining them includes moderating incoming messages and new subscriptions, keeping settings up-to-date and dealing with changes to the schemes for each price plan.

  • Maintainers: broonie, khilman


The KernelCI Slack channel may be used as an alternative to IRC. However, more people are using IRC so Slack is only there to facilitate communication when IRC is not practical.

  • Maintainers: khilman, spbnick, gtucker


The KernelCI Twitter account is used to engage with a wider public audience: events, kernel developers, other test systems… It is also a way for the project to quickly share updates about the project’s news and, achievements.

  • Maintainers: gtucker, padovan update emails (paused)

Emails are sent regularly with a summary of the changes going into production and minutes from the various TSC and board meetings.

  • Maintainers: gtucker
Last modified September 23, 2021