test(integration): cover the premade NixOS base image in the distro matrix - #3498
Conversation
…atrix The tar-only publish gate in nixos-base-image.yml cannot catch a base image that does not boot: the pre-shim 26.05 image passed every tar assertion and still froze at boot with no units. Building a template from the published image and reaching ready exercises the parts that are still ours — the busybox Bootstrap standing in for the missing FHS userland, the /sbin/e2b-nixos-init activation shim, and the /etc/systemd/system drop-in removal that lets setup-etc take over. Pinned to the immutable tag, never :latest: phases/base/hash.go keys the base layer on the image reference as written, so a republished :latest would keep building from the stale cached layer and a CI failure would not reproduce.
PR SummaryLow Risk Overview Reviewed by Cursor Bugbot for commit 65b25d0. Bugbot is set up for automated code reviews on this repo. Configure here. |
Codecov Report✅ All modified and coverable lines are covered by tests. 📢 Thoughts on this report? Let us know! |
There was a problem hiding this comment.
LGTM — straightforward test-only addition.
Extended reasoning...
Overview
This PR adds a single new test case (NixOS premade base image) to the existing table-driven TestTemplateBuildDistroFamilies test in tests/integration/internal/tests/api/templates/distro_build_test.go. It follows the exact same pattern as the four existing distro cases (Debian, RPM, Arch, Alpine), just with a different fromImage and comments explaining why the NixOS case validates boot plumbing rather than package installation. No production code is touched.
Security risks
None. This is a test-only change; it does not touch auth, crypto, permissions, or any production code path.
Level of scrutiny
Low. The change is additive, mechanical, and isolated to a single test file, following an established pattern already used for other distros in the same test. I verified that the referenced supporting infrastructure this PR's comments rely on (.github/workflows/nixos-base-image.yml and the e2b-nixos-init shim under packages/orchestrator/pkg/template/build/phases/base/distro/nixos-base-image) actually exists in the repo, so the rationale in the description is grounded in real code rather than aspirational.
Other factors
The image tag is pinned to an immutable version (26.05-20260731) rather than :latest, consistent with the PR's own stated rationale about cache-key stability in phases/base/hash.go. The PR author also thoughtfully addressed CI cost/timing implications and the compression-tests.tsv question in the description, which is good diligence for a test-only PR that adds runtime to CI. No bugs were found by the bug hunting system, and my own read of the diff didn't surface anything beyond that.
Adds the premade NixOS image to
TestTemplateBuildDistroFamilies, so CI catches a base image that doesn't boot. The tar-only publish gate innixos-base-image.ymlprovably can't: the pre-shim 26.05 image passed every tar assertion and still froze at boot with no units. The profile installs nothing, so reaching ready proves exactly the parts that are ours — the busyboxBootstrap, the/sbin/e2b-nixos-initshim (#3478), and therm -rf /etc/systemd/systemthat letssetup-etctake over.Immutable tag, never
:latest—phases/base/hash.gokeys the base layer onConfig.FromImageas written, so a republished:latestwould keep building from the stale cached layer and a failure wouldn't reproduce.Cost, measured on this run. Lands in
templates-builds-2(DistromissesTEMPLATE_BUILDS_SHARD1_RE). The subtest is 156s — 515 MB compressed / 1.05 GiB unpacked, cold pull every time. Package wall 166s → 255s, job 5.7 → 7.2 min against a 30 min cap. It grows the wall by more than 156/4 because the pull and unpack also slow its three concurrent neighbours (utilisation 3.7× → 3.0×). That makes shard 2 the long pole against shard 1's 4m52s; leavingTEMPLATE_BUILDS_SHARD1_REalone — that 2.3 min gap wants its own measuring run, the way #3479 did it.compression-tests.tsv: no change. The test is already absent; the documented criterion is reading a snapshot back, and provisioning is compression-invariant like the other four cases. Entries are per top-level test anyway, so a subtest couldn't be listed on its own.