Record the runner-mode requirement for Orin builds
A container-mode runner builds against the image's glibc, not the Orin's, which discards the reason for building on the target in the first place. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013kj58Jugkic783b8ZrtTVZ
This commit is contained in:
@@ -178,6 +178,21 @@ It detects, it does not fix; the fix is building on a unit whose release matches
|
||||
the car's. Exit 2 is distinct on purpose: a check that cannot check must not
|
||||
report success.
|
||||
|
||||
##### The runner must build on the host, not in an arbitrary container
|
||||
|
||||
⚠ **A container-mode runner discards the entire guarantee.** Jobs then build in
|
||||
whatever image the workflow names — `rust:latest` carries a much newer glibc — and
|
||||
the Orin being the host is irrelevant. The binary compiles cleanly and fails to
|
||||
load on the car unit.
|
||||
|
||||
So either run `act_runner` in **host mode**, or give it an image built from the
|
||||
same Ubuntu release as the car Orin. `scripts/check-glibc.sh` catches the mistake
|
||||
either way, which is the second reason it is worth having.
|
||||
|
||||
The runner needs a writable toolchain: rustup is installed per-user, so the
|
||||
runner either runs as a user that owns one or gets its own. A root-owned shared
|
||||
install cannot have targets added to it without `RUSTUP_ALLOW_SHARED_WRITE`.
|
||||
|
||||
##### Cross-compiling from the workstation
|
||||
|
||||
Available as a fallback. Each service repo's `.cargo/config.toml` points at
|
||||
|
||||
Reference in New Issue
Block a user