Topic starter
10/06/2026 10:57 pm
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.
Editorial analysis by NHI Mgmt Group, based on content published by Riptides: “On-Demand Driver Builds: How We Replaced Speculative Kernel Builds with a Demand-Driven Pipeline”.
Key questions
Q: What should teams do first when a required kernel package is not already built?
A: Check the artifact store first and only trigger a build when the exact package is absent.
Q: Why do on-demand kernel builds work better than speculative prebuilding for long-tail fleets?
A: Speculative prebuilding wastes CI capacity on kernel variants that may never appear in production, while on-demand builds spend compute only when a real node proves the need.
Q: What breaks when distro version is not part of the build identity?
A: Different distro versions can ship different toolchains and metadata expectations, so a module may compile but fail to load cleanly on the target host.
Practitioner guidance
- Check for an existing artifact before triggering any build Resolve package availability from the release store first, and only dispatch a workflow when the exact kernel, architecture, distribution, and distro version are missing.
- Keep the build request fully specific Carry kernel version, architecture, distribution, distro version, and driver version through the service, workflow inputs, and build cache key so different targets do not collapse into one build.
- Add a distribution-aware fallback chain Use a deterministic path such as DNF repositories, explicit kernel URLs, and Koji or CBS fallbacks so older kernel-devel packages remain buildable after mirror turnover.
Bottom line: The core problem is not compilation alone, but whether a node can get the exact driver artifact it needs at boot without waiting for a batch cycle.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
This topic was modified 2 days ago by NHI Mgmt Group
12/06/2026 4:42 am
Demand-driven build coverage is the right control when the runtime environment is the unknown. The article shows that nightly matrix builds eventually hit a ceiling because distribution mirrors and crawler data cannot predict the exact kernel a node will boot. For identity and access practitioners, the parallel is clear: governance assumptions fail when coverage is based on catalogue completeness instead of live state. The implication is to design control points around observed runtime demand, not static expectations.
A few things that frame the scale:
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: How should teams keep kernel build coverage aligned with what the fleet actually runs?
A: Use a demand-driven source of truth that records successful builds and feeds them back into the next batch cycle. That approach keeps the matrix tied to observed fleet behaviour instead of mirror inventory or crawler completeness.
👉 Read our full editorial: Demand-driven kernel driver builds reduce coverage gaps and wait time
This post was modified 2 days ago by NHI Mgmt Group