Kernel On-Demand Driver Builds: what it means for fleet coverage

TL;DR: A demand-driven kernel build pipeline checks for an existing artifact first, then dispatches a targeted GitHub Actions build only when a node boots on an unbuilt kernel, reducing wasted CI work and waiting time for the driver to load, according to Riptides. The operational lesson is that fleet-specific build coverage beats speculative precompilation when the long tail keeps changing.

NHIMG editorial — based on content published by Riptides: Kernel On-Demand Driver Builds: How We Replaced Speculative Kernel Builds with a Demand-Driven Pipeline

By the numbers:

• The current batch covers roughly 540 variants across Ubuntu, Amazon Linux, Fedora, Debian, and CentOS, on both x86_64 and aarch64.
• The maximum wait is 15 minutes before the build is marked as timed out.

Questions worth separating out

Q: How should teams handle kernel variants that are not in the prebuilt set?

A: Teams should route those misses through a demand-driven build path that first checks for an existing artifact, then dispatches a precise build only when the exact kernel, architecture, and distribution combination is absent.

Q: Why does distro version matter for kernel module builds?

A: Distro version matters because compiler toolchains and module metadata can differ across releases even when the kernel family is the same.

Q: What breaks when kernel header sources age out of standard mirrors?

A: Long-tail kernels become unbuildable if the pipeline depends only on ordinary repositories.

Practitioner guidance

• Check for an existing artifact before dispatching a build Return the prebuilt package immediately when GitHub Releases already contains the exact kernel, architecture, distribution, and distro version combination.
• Validate the full kernel identity before triggering compilation Reject requests that do not include a well-formed kernel version, architecture, distribution, and distro version.
• Maintain a fallback chain for rolled-off kernel headers Use DNF first, then explicit kernel URLs, then Koji or CBS for RPM-based systems so old kernels remain buildable after standard mirrors age them out.

What's in the full article

Riptides' full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step build-service request handling, including status polling and deduplication logic.
• The exact GitHub Actions workflow dispatch pattern used to turn a kernel miss into a build run.
• Distribution-specific fallback handling for Fedora, CentOS Stream, Debian, Ubuntu, and Amazon Linux.
• Artifact naming, package loading, and cache-key design across host, VM, and Kubernetes environments.

👉 Read Riptides' post on demand-driven kernel driver builds →

Kernel On-Demand Driver Builds: what it means for fleet coverage?

Explore further

View Full Forum →  |  NHI Foundation Course →