Build and publish signed multi-arch loreserver images to GHCR

[aleksanderllada]

Summary

Fills in publish-loreserver-image.yml, which landed earlier as a stub. Two variants publish, differing only in how arm64 is compiled:

Tag	arm64 build
X.Y.Z, X.Y, latest	baseline armv8-a — runs on any arm64 host
X.Y.Z-graviton, latest-graviton	tuned for Graviton3+, as Lore is deployed

The portable build is the default so a community chart works everywhere, and the tuned build is opt-in for Graviton deployments. linux/amd64 is baseline in both, so it is built once and both manifest lists reference that single digest.

Each variant builds on its own native runner (QEMU is far too slow for a release Rust build) and is pushed by digest; a merge job stitches the digests into manifest lists and signs each with keyless cosign. No secrets are involved: GITHUB_TOKEN authenticates to GHCR and cosign signs against Fulcio via the job's OIDC token.

Triggers on v* tags, plus manual dispatch with an optional extra tag for proving the workflow from a branch.

Why two tags rather than one

OCI cannot express this. platform.variant covers v6/v7/v8, not microarchitecture, and nothing in the pull path consults CPU features — Graviton3, Ampere Altra and Apple Silicon are all just linux/arm64. A client cannot be steered to the right arm64 build automatically, so a separate tag is the only honest mechanism.

Architecture selection itself is unaffected: one tag still serves both amd64 and arm64, which is why -graviton is also multi-arch and a mixed-architecture cluster can pin a single tag.

Dockerfile changes worth reviewing

arm64 codegen. .cargo/config.toml pins aarch64-unknown-linux-gnu to Graviton3+ with -C target-cpu=neoverse-512tvb. The Dockerfile now assembles RUSTFLAGS itself from an ARM64_TARGET_CPU build arg, empty by default. It has to be RUSTFLAGS and not CARGO_TARGET_<triple>_RUSTFLAGS: the latter is only another source for the same config key and cargo joins config arrays, so the Graviton flag survives and a supposedly-baseline build still faults.

Debug info. [profile.release-lto] sets debug = 2, and a fat-LTO link holds the whole dependency graph's DWARF at once — rustc was SIGKILLed part way through linking on a 16 GB runner. Building with -C debuginfo=0 fixes it and costs nothing observable, because strip --strip-debug discarded that DWARF a line later anyway and tracing's file/line fields come from compile-time macros. Side effect: the arm64 image drops from 100 MB to 51 MB.

DOCKER.md documents both variants and the build arg.

Test evidence

A full dispatch published both variants, each signed and verified in-run. The amd64 digest is shared, as intended:

ci-test           linux/amd64  sha256:0d523ba6fe18a113…
                  linux/arm64  sha256:a06281c562b9d2f5…
ci-test-graviton  linux/amd64  sha256:0d523ba6fe18a113…   <- identical
                  linux/arm64  sha256:a45916979f3d0653…   <- differs

Both arm64 images were then run on an Apple M3 Max, which has no SVE:

default  arm64 -> loreserver 0.9.1-nightly     exit=0
graviton arm64 -> Illegal instruction          exit=132

That is the intended behaviour of both variants, and it is the only test that actually distinguishes them. The default image also boots and serves — 10 QUIC listeners on 0.0.0.0:41337.

A limitation to be aware of

The per-arch smoke step runs the freshly pushed image, which catches a broken entrypoint or a missing shared library. It does not catch codegen aimed at a CPU the eventual host lacks: GitHub's arm64 runner is Neoverse-N2 and reports SVE, so it executes the Graviton-tuned build without complaint. This was measured, not assumed, and it is why the Apple Silicon check above matters. A CI gate running the binary under qemu-aarch64 -cpu cortex-a72 would close it and is not yet implemented.

Notes

• Follows the conventions in the surrounding workflows: SPDX header, top-level permissions: {}, per-job least privilege with justification comments, and every action pinned to a full commit SHA.
• The cosign identity is anchored on this workflow's path, not just the repository, so a certificate minted by any other workflow here will not verify.
• The ci-test and ci-test-graviton tags are leftovers from proving this and will be deleted.
• This is opened for review and CI; the change reaches main through the usual mirror path rather than by merging here.

[duncangrist]

Can you ensure you run a /code-review in CC as my review brought up a few things.

Also, two CI jobs are failing currently.