build: publish a pinned kernel build environment image#209
Merged
Conversation
Kernel builds currently construct their build environment from scratch on every matrix job: a digest-pinned debian:bookworm base, plus build-essential, cross compilers, and supporting tools installed from the Debian archive at build time. The base pin does not pin the toolchain - apt installs whatever bookworm serves that day (gcc-12 is at 12.2.0-14+deb12u1 and counting), so toolchain updates arrive silently on whatever build happens to run first. That matters more once compile caching keys on the compiler binary's content hash: an unplanned gcc update turns a random build into a 100% cache miss. It also costs about 80 seconds of apt work per job, repeated across every job in the matrix. Introduce ghcr.io/edera-dev/kernel-buildenv, built from Dockerfile.buildenv: the same toolchain as today (debian:bookworm + build-essential + cross compilers) plus a pinned, checksum-verified sccache release with compiler wrapper scripts in /usr/lib/sccache, ready for the compile-cache work that consumes this image. A new workflow builds it natively per arch (amd64/arm64), assembles a manifest list tagged latest and YYYYMMDD, and cosign-signs it - on the 1st and 15th of each month, on demand, and on changes to Dockerfile.buildenv. The twice-monthly cadence makes toolchain updates deliberate, dated events instead of continuous drift. The image is self-describing: the last layer bakes a sorted dpkg package manifest (plus the sccache version) into /usr/share/buildenv/packages.tsv, so any two image digests can be diffed without external records. A companion PR workflow uses that to summarize exactly which packages changed whenever a PR bumps the kernel-buildenv digest pin in the kernel Dockerfile (dependabot's docker ecosystem already watches such pins), so version bumps arrive as reviewable diffs rather than opaque digest changes. Nothing consumes the image yet; wiring the kernel Dockerfile to build FROM it happens separately once the first image is published. Signed-off-by: Steven Noonan <steven@edera.dev>
tycho
requested review from
alexandermerritt,
azenla,
bleggett and
kaniini
as code owners
bleggett
approved these changes
Jul 14, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Kernel builds assemble their toolchain from the Debian archive on every matrix job, so the base image digest pin does not actually pin the compilers: apt installs whatever bookworm serves that day, and toolchain updates land silently on whatever build runs first. With compile caching keyed on the compiler binary (#208), an unplanned gcc update silently turns a random build into a full cache miss, and the per-job apt work costs about 80 seconds times every job in the matrix.
This introduces
ghcr.io/edera-dev/kernel-buildenv, a published build-environment image containing the existing toolchain plus a pinned sccache release. A new workflow rebuilds and publishes it natively for amd64 and arm64 on the 1st and 15th of each month (and on demand), taggedlatestplus aYYYYMMDDdate tag, cosign-signed. The kernel Dockerfile will consume it by digest, with dependabot proposing bumps the same way it already does for the debian and alpine pins - making toolchain updates deliberate, reviewed events on a predictable cadence.Each image bakes its own package manifest into
/usr/share/buildenv/packages.tsv, and a companion workflow diffs the old and new manifests into the check summary whenever a PR changes the digest pin, so a dependabot bump shows exactly which packages changed instead of an opaque digest.Nothing consumes the image yet; #208 wires the kernel build to it once the first image is published.