From fd59a7491259935540fe3786a86fbc9bb720f2e1 Mon Sep 17 00:00:00 2001 From: wtclaude Date: Wed, 5 Aug 2026 05:22:59 -0500 Subject: [PATCH] ci(bundle): recognize a linux-aarch64 link asset MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 --- .gitea/workflows/bundle.yml | 14 ++++++++++++-- bundles/README.md | 4 +++- 2 files changed, 15 insertions(+), 3 deletions(-) diff --git a/.gitea/workflows/bundle.yml b/.gitea/workflows/bundle.yml index ddfa4c4..f8cf20e 100644 --- a/.gitea/workflows/bundle.yml +++ b/.gitea/workflows/bundle.yml @@ -173,13 +173,23 @@ jobs: # Map link's binaries onto platform keys. The pattern is asserted, not # assumed: an unrecognized asset name is a hard failure so that adding - # a target to link's release.yml (aarch64, macOS) surfaces here as a - # red run, rather than being silently dropped from every bundle. + # a target to link's release.yml (macOS, a Windows arm64) surfaces here + # as a red run, rather than being silently dropped from every bundle. + # + # linux-aarch64 is recognized here BEFORE link publishes one + # (PLAN.md §5.2, step 1 of 4). That order is forced by the two rules + # below being strict in opposite directions: an unknown name fails the + # run, and a missing REQUIRED key fails it too. So the name has to be + # taught before the release that carries it, and the key can only be + # required after — requiring it first would fail every bundle for as + # long as the gap lasts. Step 3 promotes it into REQUIRED once a link + # release actually ships the binary. : > work/link-platforms.tsv while IFS="$(printf '\t')" read -r NAME URL; do [ -n "$NAME" ] || continue case "$NAME" in *-linux-x86_64) PLAT=linux-x86_64 ;; + *-linux-aarch64) PLAT=linux-aarch64 ;; *-windows-x86_64.exe) PLAT=windows-x86_64 ;; *) fail "unrecognized link asset '${NAME}' — bundle.yml does not know what platform to file it under. Teach it this name or the bundle would silently omit the asset." ;; esac diff --git a/bundles/README.md b/bundles/README.md index 315c949..bdb62a6 100644 --- a/bundles/README.md +++ b/bundles/README.md @@ -56,9 +56,11 @@ protocol) or to either component's release version. All three move independently "tag": "v1.1.0", "version": "1.1.0", "protocol": 3, - "assets": { // per-platform: the installer runs on both + "assets": { // per-platform: the installer runs on each "linux-x86_64": { "name": "…", "url": "…", "sha256": "…" }, "windows-x86_64": { "name": "…", "url": "…", "sha256": "…" } + // "linux-aarch64" joins these from link's first release built for it; + // bundle.yml already knows the name (PLAN.md §5.2) } },