ci(bundle): recognize a linux-aarch64 link asset #9

wtclaude · 2026-08-05T10:23:20Z

wtclaude commented

2026-08-05 10:23:20 +00:00

What & why

Step 1 of 4 in PLAN.md §5.2 (arm64 — see docs#96 for the scope decision), and it has to be the first one.

Two rules in this job are strict in opposite directions:

an unrecognized link asset name is a hard failure (so a new target can't be silently dropped from every bundle), and
a missing REQUIRED platform key is a hard failure too (so a dropped target can't be silently dropped either).

Which means the name has to be taught before the release that carries it, and the key can only be required after one exists. Requiring it first would fail every bundle — including the nightly cron — for as long as the gap between the two merges lasts.

So this PR is the mapping only. linux-aarch64 is not in REQUIRED yet; step 3 promotes it once a link release actually ships the binary, and from that point a dropped target reddens CI.

The compose step needed no change: it builds the asset map by folding the platform TSV, so a third key costs it nothing (that generality is the same one §7.1 noted when the map replaced a single sha256).

Edited on main and deliberately not on edge. The compose job runs from main, and leaving edge's copy untouched means the eventual edge → main cutover merge has nothing to conflict over. edge is currently a strict superset of main and both copies of this workflow are byte-identical, so this is the one change that has to break that symmetry — in the direction that costs nothing.

How it was tested

bundle.yml parses as YAML.
The case arms were run against the four names that matter — the two link publishes today, the one it will publish, and a .deb — confirming no arm shadows another and that an unknown name still reaches fail:

uo-link-sidecar-linux-x86_64             -> linux-x86_64
uo-link-sidecar-linux-aarch64            -> linux-aarch64
uo-link-sidecar-windows-x86_64.exe       -> windows-x86_64
runicgateway-link_1.1.0_amd64.deb        -> FAIL(unrecognized)

The last line is the intended behaviour, not a gap: §5.1 dropped the .deb, and if one ever appears this job should stop rather than guess.

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 **1 of 4** in [PLAN.md §5.2](https://gitea.whitlocktech.com/RunicGateway/docs/src/branch/main/installer/PLAN.md) (arm64 — see docs#96 for the scope decision), and it has to be the first one. Two rules in this job are strict in **opposite** directions: - an unrecognized `link` asset name is a hard failure (so a new target can't be silently dropped from every bundle), and - a missing `REQUIRED` platform key is a hard failure too (so a *dropped* target can't be silently dropped either). Which means the name has to be taught **before** the release that carries it, and the key can only be required **after** one exists. Requiring it first would fail every bundle — including the nightly cron — for as long as the gap between the two merges lasts. So this PR is the mapping only. `linux-aarch64` is **not** in `REQUIRED` yet; step 3 promotes it once a `link` release actually ships the binary, and from that point a dropped target reddens CI. The compose step needed no change: it builds the asset map by folding the platform TSV, so a third key costs it nothing (that generality is the same one §7.1 noted when the map replaced a single `sha256`). **Edited on `main` and deliberately not on `edge`.** The compose job runs from `main`, and leaving `edge`'s copy untouched means the eventual `edge → main` cutover merge has nothing to conflict over. `edge` is currently a strict superset of `main` and both copies of this workflow are byte-identical, so this is the one change that has to break that symmetry — in the direction that costs nothing. ## How it was tested - `bundle.yml` parses as YAML. - The `case` arms were run against the four names that matter — the two link publishes today, the one it will publish, and a `.deb` — confirming no arm shadows another and that an unknown name still reaches `fail`: ``` uo-link-sidecar-linux-x86_64 -> linux-x86_64 uo-link-sidecar-linux-aarch64 -> linux-aarch64 uo-link-sidecar-windows-x86_64.exe -> windows-x86_64 runicgateway-link_1.1.0_amd64.deb -> FAIL(unrecognized) ``` The last line is the intended behaviour, not a gap: §5.1 dropped the `.deb`, and if one ever appears this job should stop rather than guess. ## 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:23:21 +00:00

ci(bundle): recognize a linux-aarch64 link asset

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

Details

fd59a74912

Step 1 of PLAN.md §5.2's four, and it has to be first. Two rules in this
job are strict in opposite directions: an unrecognized link asset name
fails the run, and a missing REQUIRED platform key fails it too. So the
name must be taught before the release that carries it, and the key can
only be required after one exists -- requiring it first would fail every
bundle for as long as the gap lasts.

This is therefore the mapping only. linux-aarch64 is not in REQUIRED
yet; step 3 promotes it once a link release actually ships the binary,
after which a dropped target reddens CI instead of vanishing silently
from every bundle.

The compose step needed no change: it builds the asset map from the
platform TSV, so a third key costs it nothing.

Edited on `main` and deliberately not on `edge`. The compose job runs
from `main`, and leaving `edge`'s copy untouched means the eventual
cutover merge has nothing to conflict over.

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

whitlocktech approved these changes 2026-08-05 17:51:01 +00:00

whitlocktech merged commit ae53546446 into main

2026-08-05 17:51:11 +00:00

whitlocktech deleted branch ci/bundle-aarch64-key

2026-08-05 17:51:12 +00:00

whitlocktech referenced this issue from a commit

2026-08-05 17:51:13 +00:00

Merge pull request 'ci(bundle): recognize a linux-aarch64 link asset' (#9) from ci/bundle-aarch64-key into main

Sign in to join this conversation.

2 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: RunicGateway/installer#9