The runner image's apt sources do not carry pykickstart
(E: Unable to locate package). python3-yaml stays apt; ksvalidator is
pip-installed system-wide so the test job finds it on PATH.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V6HNx6cyr4J4CiMGCy1wkF
ubuntu-autoinstall.test.ts and layout-consistency.test.ts parse the
rendered autoinstall YAML with python3+yaml, and kickstart.test.ts runs
ksvalidator -- none of which the runner image ships. 35 of the 569 tests
failed on exactly that, the same set that fails on a bare workstation.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V6HNx6cyr4J4CiMGCy1wkF
Every job on main has been failing at setup: pnpm/action-setup@v4 reads
packageManager from the package.json at the REPO ROOT, and a job-level
working-directory default does not apply to `uses:` steps, so the pin in
bastion/package.json was never seen ("No pnpm version is specified").
Point the action at bastion/package.json so the version stays declared
in exactly one place.
Past setup, typecheck/test/build would then hit the next wall: labd's
generated Prisma client does not exist after a fresh install (no
postinstall hook, by design), and tsc --build fails on it. Run
`pnpm -C src/labd run db:generate` right after install in the jobs that
compile.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01V6HNx6cyr4J4CiMGCy1wkF
- build-rpm.sh: --arch flag for targeting x86_64 or arm64, --all for both
Uses bun cross-compile with --target=bun-linux-x64/arm64
- build-bastion.sh: --arch flag for Docker platform targeting
- release.sh: builds both architectures by default
- CI: builds + publishes RPM/DEB for both architectures
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
