test(smoke): make CI prove the natives still work — the runbook check didn't
The post-boot check v1.9.1 left for the next machine was
node -e 'require("esbuild").transformSync("const x:number=1",{loader:"ts"})'
with "if this fails, the prune removed something needed on arm64 -> revert to
v1.8.14 and fix" attached. Run from /workspace on the freshly recreated v1.9.1
image it fails with MODULE_NOT_FOUND — on a perfectly healthy image. require()
resolves by walking up from the CURRENT DIRECTORY, esbuild is nested inside the
two pi trees, and a global install is not on node's require path (NODE_PATH is
unset). The version that "verified the prune" last night only passed because the
shell happened to sit inside the tree. So the check was CWD-dependent, its red
meant nothing, and the remedy it prescribed was reverting a good release.
Path-qualified, both sites compile TS today. Rather than leave a fragile command
in a note for a human to paste, CI now owns it:
- esbuild must transformSync at EVERY install site found in the image
- @mariozechner/clipboard must load with its native binding attached at every
site — for the clipboard prune that IS the proof, since napi-rs resolves the
platform package at require() time
Sites are discovered with find, so the studio variant's third site is covered
without naming it.
Verified as a four-way matrix, not just a green run: both assertions pass
against the real image FROM /workspace (the cwd that broke the old command), and
both fail (exit 1, "The package \"@esbuild/linux-arm64\" could not be found, and
is needed by esbuild") against copies of the same packages with the host
platform binary removed. An assertion never observed failing is not evidence.
Also documents both failure shapes in AGENTS.md next to the size gate: this one,
and the mode-700 /root one where `test ! -d` passes on a permission error.
This commit is contained in:
@@ -78,6 +78,24 @@ RUN at the end of `Dockerfile.variant` calls `pi --version` again, so deleting
|
||||
it earlier only relocates those bytes into that layer — today's manifest layer
|
||||
is 128 kB precisely because it finds the cache warm.
|
||||
|
||||
**Two functional assertions as well, after the runbook command left for the
|
||||
next machine failed for the wrong reason.** v1.9.1's open item prescribed
|
||||
`node -e 'require("esbuild").transformSync(...)'` as the post-boot check, with
|
||||
"if this fails, the prune removed something needed → revert to v1.8.14". Run
|
||||
from `/workspace` it fails with `MODULE_NOT_FOUND` on a perfectly good image:
|
||||
`require` resolves by walking up from the current directory, esbuild lives
|
||||
nested inside the two pi trees, and global installs are not on node's require
|
||||
path (`NODE_PATH` is unset). The check that verified the prune last time only
|
||||
passed because the shell happened to be inside the tree. Smoke now does it
|
||||
properly and CI owns it: for every install site found in the image (so the
|
||||
studio variant's third site is covered automatically), esbuild must compile TS
|
||||
and `@mariozechner/clipboard` must load with its native binding attached — the
|
||||
latter is the real proof for the clipboard prune, since napi-rs resolves the
|
||||
platform package at `require()` time. Both were verified as a four-way matrix:
|
||||
green on the real image *from `/workspace`*, and red against copies of the same
|
||||
packages with the host platform binary removed (`The package
|
||||
"@esbuild/linux-arm64" could not be found`).
|
||||
|
||||
Touches `Dockerfile.variant` and `scripts/smoke-test.sh` only: `Dockerfile.base`
|
||||
is unchanged, so this needs no base rebuild and should **ride the next release**
|
||||
rather than burn a cycle of its own.
|
||||
|
||||
Reference in New Issue
Block a user