ci(release): build and publish a linux-aarch64 sidecar #26

Merged
whitlocktech merged 1 commits from ci/release-linux-aarch64 into main 2026-08-05 17:52:42 +00:00
Member

What & why

Step 2 of 4 in the installer's PLAN.md §5.2 (scope decision in docs#96).

The shard dials the sidecar out on loopback, so wherever ServUO runs, this binary has to run too — and Ampere/Graviton instances and Pi-class boxes are a realistic ServUO home. Until now this workflow cross-compiled x86_64 Linux and Windows only, which is why the installer refuses every arm64 host by name.

The part that isn't boilerplate

Cross-compiling this crate is not Rust-only: sqlx's sqlite feature pulls libsqlite3-sys, which compiles bundled SQLite from C. So the build needs a CC/AR pair as well as a linker — the same shape the Windows step already carries for MinGW.

And libc6-dev-arm64-cross is named explicitly, because gcc-aarch64-linux-gnu only recommends it while this install passes --no-install-recommends. With the compiler alone the cross toolchain is present and SQLite still fails:

cargo:warning=/usr/include/stdio.h:27:10: fatal error: bits/libc-header-start.h: No such file or directory
error occurred in cc-rs: command did not execute successfully ... "aarch64-linux-gnu-gcc" ... "-c" "sqlite3/sqlite3.c"

That is the failure CI would have hit on the first arm64 release, and it is invisible until something in the dependency tree compiles C.

How it was tested

Both the failure and the fix were reproduced against this crate in a rust:1-slim-bookworm container — same base, same --no-install-recommends discipline, same env vars the workflow now sets:

   Compiling uo-link-sidecar v0.1.0 (/src/sidecar)
    Finished `release` profile [optimized] target(s) in 1m 29s
=== result ===
uo-link-sidecar: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV),
dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0

release.yml also parses as YAML.

The new binary is added to SHA256SUMS and to the upload list. Both are required: the installer verifies each download against those sums, and sha256sum -c passes silently over a file the sums list does not mention (the same asymmetry the bundle CI's gate 2 guards against from the other side).

⚠ Merge order

installer#9 must land first. It teaches the bundle CI this asset name; an unrecognized link asset there is a hard failure by design, so a release published before it would redden the compose job and pin operators to a stale bundle until it was fixed.

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 **2 of 4** in the installer's [PLAN.md §5.2](https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/installer/PLAN.md) (scope decision in docs#96). The shard **dials the sidecar out on loopback**, so wherever ServUO runs, this binary has to run too — and Ampere/Graviton instances and Pi-class boxes are a realistic ServUO home. Until now this workflow cross-compiled x86_64 Linux and Windows only, which is why the installer refuses every arm64 host by name. ### The part that isn't boilerplate Cross-compiling *this* crate is not Rust-only: `sqlx`'s `sqlite` feature pulls `libsqlite3-sys`, which compiles **bundled SQLite from C**. So the build needs a `CC`/`AR` pair as well as a linker — the same shape the Windows step already carries for MinGW. And `libc6-dev-arm64-cross` is named explicitly, because `gcc-aarch64-linux-gnu` only *recommends* it while this install passes `--no-install-recommends`. With the compiler alone the cross toolchain is present and SQLite still fails: ``` cargo:warning=/usr/include/stdio.h:27:10: fatal error: bits/libc-header-start.h: No such file or directory error occurred in cc-rs: command did not execute successfully ... "aarch64-linux-gnu-gcc" ... "-c" "sqlite3/sqlite3.c" ``` That is the failure CI would have hit on the first arm64 release, and it is invisible until something in the dependency tree compiles C. ## How it was tested Both the failure **and** the fix were reproduced against this crate in a `rust:1-slim-bookworm` container — same base, same `--no-install-recommends` discipline, same env vars the workflow now sets: ``` Compiling uo-link-sidecar v0.1.0 (/src/sidecar) Finished `release` profile [optimized] target(s) in 1m 29s === result === uo-link-sidecar: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0 ``` `release.yml` also parses as YAML. The new binary is added to `SHA256SUMS` **and** to the upload list. Both are required: the installer verifies each download against those sums, and `sha256sum -c` passes silently over a file the sums list does not mention (the same asymmetry the bundle CI's gate 2 guards against from the other side). ## ⚠ Merge order **installer#9 must land first.** It teaches the bundle CI this asset name; an unrecognized `link` asset there is a hard failure *by design*, so a release published before it would redden the compose job and pin operators to a stale bundle until it was fixed. ## 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:29:39 +00:00
ci(release): build and publish a linux-aarch64 sidecar
All checks were successful
PR Checks / rust-gates (pull_request) Successful in 1m17s
65b12f815b
Step 2 of installer PLAN.md §5.2. The shard dials the sidecar out on
loopback, so wherever ServUO runs this binary has to run too -- and
Ampere/Graviton instances and Pi-class boxes are a realistic ServUO
home. Until now the release cross-compiled x86_64 Linux and Windows
only, so the installer refused every arm64 host by name.

Cross-compiling this crate is not Rust-only: sqlx's sqlite feature
pulls libsqlite3-sys, which compiles bundled SQLite from C. The build
therefore needs a CC/AR pair as well as a linker, the same shape the
Windows step already has.

libc6-dev-arm64-cross is named explicitly because gcc-aarch64-linux-gnu
only recommends it and this install passes --no-install-recommends: with
the compiler alone, SQLite's build dies on

  /usr/include/stdio.h:27: fatal error: bits/libc-header-start.h

Both the failure and the fix were reproduced in a rust:1-slim-bookworm
container against this crate before the workflow was written.

The new binary is added to SHA256SUMS and to the upload list. Every
artifact has to appear in both: the installer verifies its download
against those sums, and `sha256sum -c` passes silently over a file the
sums list does not mention.

Merge order matters -- installer#9 teaches the bundle CI this asset
name, and must land first. An unrecognized link asset is a hard failure
there, by design, so a release published before it would redden the
compose job.

Co-Authored-By: Claude <noreply@anthropic.com>
whitlocktech merged commit 2724c292a0 into main 2026-08-05 17:52:42 +00:00
whitlocktech deleted branch ci/release-linux-aarch64 2026-08-05 17:52:43 +00:00
Sign in to join this conversation.
No description provided.