feat(installer): build for and install on linux-aarch64 #10

wtclaude · 2026-08-05T10:34:37Z

wtclaude commented

2026-08-05 10:34:37 +00:00

What & why

Step 4 of 4 in PLAN.md §5.2 (scope in docs#96; steps 1–3 are installer#9, link#26, and the follow-up that promotes the key to required).

This is the half an operator sees: release.yml cross-compiles aarch64-unknown-linux-gnu, and platform_key() resolves ("linux", "aarch64") to the bundle key link publishes under instead of refusing the host by name.

Toolchain shape is the Windows step's — a linker plus a CC/AR pair, because ring (under ureq's rustls) compiles C and assembly — and libc6-dev-arm64-cross is named explicitly for the same --no-install-recommends reason documented in link#26.

Two test changes fall out of the asset map growing a key

assets.len() == 2 is replaced by a check that each key CI requires is present and well-formed. An exact count would fail on the very first bundle that adds arm64 — reporting correct behaviour as a regression.
The host-binary lookup now accepts either outcome and asserts the explanation. Bundles are kept unchanged forever so --bundle stays reproducible, which means one published before arm64 existed can never gain that key retroactively. On an arm64 host reading such a bundle the run must fail with the reason, not with something that reads like a corrupt document, so sidecar_asset()'s error now says so:

bundle 2026.08.04 has no uo-link binary for linux-aarch64 (it has: linux-x86_64, windows-x86_64).
Bundles published before uo-link built for this platform cannot gain one retroactively — they are kept unchanged so --bundle stays reproducible. Run without --bundle to take the current one.

How it was tested

Cross-built this crate for aarch64 in a rust:1-slim-bookworm container with exactly the packages and env vars the workflow sets:
runicgateway-installer: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1
cargo fmt --check, cargo clippy --all-targets -- -D warnings and cargo test on both Linux (Docker) and the Windows host — 131 + 9 tests green on each. Both platforms are checked because only half of service.rs compiles on either.

Not tested, and deliberately: executing the arm64 binary. That needs an emulator or real hardware, and the risk this PR carries is a build one — the run-time paths it touches are the same code x86_64 already exercises.

Checklist

I have read CONTRIBUTING.md.
The change builds and existing tests/checks pass locally.
I have added or updated tests/docs where it makes sense.
My commits are reasonably scoped with clear messages.

AI-assisted contributions (required)

No AI tools were used to produce this contribution.
AI tools were used. Tool(s): Claude Code (Opus 5). I have reviewed and understand every change, and take responsibility for it. AI-authored commits are marked with a Co-Authored-By trailer.

License

I agree that my contribution is licensed under this project's license (GNU GPL v3.0 or later), and I have the right to contribute it.

## What & why Step **4 of 4** in [PLAN.md §5.2](https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/installer/PLAN.md) (scope in docs#96; steps 1–3 are installer#9, link#26, and the follow-up that promotes the key to required). This is the half an operator sees: `release.yml` cross-compiles `aarch64-unknown-linux-gnu`, and `platform_key()` resolves `("linux", "aarch64")` to the bundle key link publishes under instead of refusing the host by name. Toolchain shape is the Windows step's — a linker plus a `CC`/`AR` pair, because `ring` (under `ureq`'s rustls) compiles C and assembly — and `libc6-dev-arm64-cross` is named explicitly for the same `--no-install-recommends` reason documented in link#26. ### Two test changes fall out of the asset map growing a key - `assets.len() == 2` is replaced by a check that each key CI *requires* is present and well-formed. An exact count would fail on the very first bundle that adds arm64 — reporting correct behaviour as a regression. - The host-binary lookup now accepts **either** outcome and asserts the explanation. Bundles are kept unchanged forever so `--bundle` stays reproducible, which means one published before arm64 existed can never gain that key retroactively. On an arm64 host reading such a bundle the run must fail with the *reason*, not with something that reads like a corrupt document, so `sidecar_asset()`'s error now says so: > bundle 2026.08.04 has no uo-link binary for linux-aarch64 (it has: linux-x86_64, windows-x86_64). > Bundles published before uo-link built for this platform cannot gain one retroactively — they are kept unchanged so `--bundle` stays reproducible. Run without `--bundle` to take the current one. ## How it was tested - **Cross-built this crate for aarch64** in a `rust:1-slim-bookworm` container with exactly the packages and env vars the workflow sets: `runicgateway-installer: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1` - `cargo fmt --check`, `cargo clippy --all-targets -- -D warnings` and `cargo test` on **both** Linux (Docker) and the Windows host — 131 + 9 tests green on each. Both platforms are checked because only half of `service.rs` compiles on either. Not tested, and deliberately: executing the arm64 binary. That needs an emulator or real hardware, and the risk this PR carries is a *build* one — the run-time paths it touches are the same code x86_64 already exercises. ## Checklist - [x] I have read [CONTRIBUTING.md](CONTRIBUTING.md). - [x] The change builds and existing tests/checks pass locally. - [x] I have added or updated tests/docs where it makes sense. - [x] My commits are reasonably scoped with clear messages. ## AI-assisted contributions (required) - [ ] No AI tools were used to produce this contribution. - [x] AI tools were used. Tool(s): `Claude Code (Opus 5)`. I have reviewed and understand every change, and take responsibility for it. AI-authored commits are marked with a `Co-Authored-By` trailer. ## License - [x] I agree that my contribution is licensed under this project's license (**GNU GPL v3.0 or later**), and I have the right to contribute it.

wtclaude added 1 commit 2026-08-05 10:34:38 +00:00

feat(installer): build for and install on linux-aarch64

PR Checks / rust-gates (pull_request) Successful in 54s

Details

6941925fa5

Step 4 of PLAN.md §5.2, and the half that faces the operator: the
release now cross-compiles aarch64-unknown-linux-gnu, and platform_key()
resolves ("linux","aarch64") to the bundle key link publishes under
instead of refusing the host by name.

Same toolchain shape as the Windows step -- a linker plus a CC/AR pair,
because ring (under ureq's rustls) compiles C and assembly. And the same
packaging trap named in the sums comment: an artifact missing from
SHA256SUMS is one `sha256sum -c` passes over silently, so the new binary
is added to both the sums and the upload list.

Two test changes fall out of the asset map growing a key:

- The exact `assets.len() == 2` assertion is replaced by a check that
  each key CI requires is present and well-formed. An exact count would
  fail on the first bundle that adds arm64 -- reporting correct
  behaviour as a regression.
- The host-binary lookup now accepts either outcome, and says why.
  Bundles are kept unchanged forever so `--bundle` stays reproducible,
  which means one published before arm64 existed can never gain that
  key. On such a host the run must fail with the reason rather than
  something that reads like a corrupt document, so sidecar_asset()'s
  error now says so and the test asserts it.

Verified by cross-building this crate for aarch64 in a
rust:1-slim-bookworm container -- ELF 64-bit LSB pie executable, ARM
aarch64 -- and by running fmt, clippy -D warnings and the tests on both
Linux and the Windows host, since only half of service.rs compiles on
either.

Co-Authored-By: Claude <noreply@anthropic.com>

whitlocktech merged commit 10bc2224a6 into edge

2026-08-05 17:53:03 +00:00

whitlocktech referenced this issue from a commit

2026-08-05 17:53:06 +00:00

Merge pull request 'feat(installer): build for and install on linux-aarch64' (#10) from ci/installer-linux-aarch64 into edge

whitlocktech deleted branch ci/installer-linux-aarch64

2026-08-05 17:53:06 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: RunicGateway/installer#10