Kernel CI – How Far Can It Go?
summary
A working KCIDB aggregator collects JSON results from eight systems and displays prototype Grafana dashboards and notifications, ingesting about 300,000 test reports per day and ~10,000 builds; current reality is nearly every revision is red because combined feeds amplify flaky hardware and test drift. Concrete proposals include pre-merge hardware testing via authenticated GitHub/GitLab integration and LAVA labs, automated known-failure detection and deduplication, and moving stable suites like LTP into the kernel tree to keep tests and code in sync.
AI-written summary · about
chapters (8)
- 0:00Introduction to kernel CI
- 2:20CI landscape and reporting
- 5:04Metrics and hard limitations
- 10:46Key challenges in testing
- 15:51Improving the CI workflow
- 20:15Triage and noise reduction
- 24:49Future directions
- 27:29Discussion and Q&A
related talks
33mKernel CI – How Far Can It Go?
40mKernelCI for Embedded: Enhancing Reliability through Scalable Test Automation
38mQuality Beyond Kernelci.Org in Upstream Linux for TI SoCs
33mMerging an existing framework into KernelCI
40mOne year into the new KernelCI
40mGetting Started With New KernelCI CLI Tools for Automating Linux Kernel Testing...
41mThe magical fantasy land of Linux kernel testing
33mUnifying and improving test regression reporting and tracking