The lifecycle of Linux kernel testing
Table of Contents
In Continuous integration testing for the Linux kernel,I wrote about the Continuous Kernel Integration (CKI) project and its mission to change how kernel developers and maintainers work. This article is a deep dive into some of the more technical aspects of the project and how all the pieces fit together. Every exciting feature, improvement, and bug in the kernel starts with a change proposed by a developer.
These changes appear on myriad mailing lists for different kernel repositories. Some repositories focus on certain subsystems in the kernel, such as storage or networking, while others focus on broad aspects of the kernel. The CKI project springs into action when developers propose a change, or patchset, to the kernel or when a maintainer makes changes in the repository itself.
The CKI project maintains triggers that monitor these patchsets and take action. Software projects such as Patchwork make this process much easier by collating multi-patch contributions into a single patch series. This series travels as a unit through the CKI system and allows for publishing a single report on the series.
Other triggers watch the repository for changes. This occurs when kernel maintainers merge patchsets, revert patches, or create new tags. Testing these critical changes ensures that developers always have a solid baseline to use as a foundation for writing new patches.
All of these changes make their way into a GitLab pipeline and pass through multiple stages and multiple systems.
Source: opensource.com
