feat(desktop): add a linux-aarch64 leg to the Desktop release matrix - #12833

Reviewed at 9b920a22. No P0/P1 — review record for a non-author maintainer vote (own PR).

Verified the load-bearing details:

• Arch tokens are correct: the manifest matches Tauri's real AppImage suffixes (_amd64 / _aarch64), not the Debian ones — and neither pattern can match the other's artifact, so the exactly-one-match invariant holds with both legs present.
• glibc floor rationale is real: the arm64 leg pins ubuntu-22.04-arm (glibc 2.35, shared with the x64 leg) rather than 24.04 (2.39), which would have produced an artifact that refuses to start on Ubuntu 22.04 / Debian 12 arm64.
• The --allow-missing-platform escape hatch is scoped exactly right: only the OSS re-mirror-of-an-existing-release path passes it (SOURCE = 'release'), fresh builds stay strict, and the tests pin all three shapes (absent without the flag fails; wrong platform name still fails; right name succeeds and omits the leg).
• The matrix↔feed cross-check test (testReleaseMatrixCoversUpdaterPlatforms) closes the original #12806 failure mode — a leg nobody taught the manifest about can no longer ship silently.
• Electron bridge correctly pins its x64-only AppImage selection in both the manifest script and the workflow glob.

CI green at this head (13 pass, 0 fail).

No confirmed blocking findings.
Approval withheld: arm64 build has never been executed (structural — PR CI cannot run the release matrix).

Scope: All 7 changed files reviewed in full. Not reviewed: arm64 build execution (requires a live release-matrix run; outside reviewer reach by construction).

What I verified:

1. All three exact-one-match sites updated correctly. On main, three code paths assert exactly one *.AppImage hit. The diff patches all three: (a) create-desktop-update-manifest.mjs switches from /.AppImage$/i to arch-specific /_amd64.AppImage$/i and /_aarch64.AppImage$/i; (b) create-electron-bridge-manifest.mjs switches to /_amd64.AppImage$/i (bridge is x64-only by design); (c) the desktop-release.yml feed-step glob switches to *_amd64.AppImage. The remaining consumers — Collect artifacts (arch-agnostic allow-list), OSS mirror asset checks (existence-only find … -print -quit), sha256sum, and gh release create — are count-agnostic and need no change.

2. allowMissingPlatforms parsing is safe. When --allow-missing-platform is absent, options['allow-missing-platform'] is undefined, falls back to '', splits to [''], trims, and filter(Boolean) removes the empty string — empty Set, strict mode. No silent opt-out.

3. The if (!artifact) continue; guard is correct. selectArtifact returns null only when zero matches are found and the platform is in allowMissingPlatforms. The continue skips both the signature check and the manifest entry. The test confirms: --allow-missing-platform linux-aarch64 produces a 4-platform manifest when arm64 artifacts are absent, while --allow-missing-platform darwin-x86_64 still fails on the missing arm64 leg — the escape hatch is per-platform, not a blanket opt-out.

4. testReleaseMatrixCoversUpdaterPlatforms correctly guards the matrix↔manifest invariant. Parses every rust_target: line in the workflow, maps it through updaterPlatformByRustTarget, and asserts symmetry against every ['platform', entry in the manifest script. This is the sentinel that prevents the silent failure cited in the PR: a leg that builds but is never registered in the feed.

5. OSS sync re-mirror gate correctly scoped. --allow-missing-platform linux-aarch64 is only injected when $SOURCE = 'release' (re-mirroring an existing GitHub release that predates arm64). Fresh source=artifact builds stay strict.

Non-blocking observations:

• Re-mirror tolerance has no version floor (sync-desktop-to-oss.yml): The source=release escape hatch is permanent. Re-mirroring a future post-arm64 release whose arm64 leg is genuinely absent would silently publish an incomplete feed instead of failing. In practice publish is strict and cannot produce such a release without clobber=true trickery, but a $VERSION >= X.Y.Z floor would make the escape hatch self-retiring.

• Test comment slightly overstates the regex guarantee (packages/desktop/scripts/test-release.js): The comment on testReleaseMatrixCoversUpdaterPlatforms says the published regex is keyed on the [platform, selectArtifact( shape "so a commented-out entry stops counting as published." The actual pattern \[\s'((?:darwin|linux|windows)-(?:x86_64|aarch64))'\s*, would still match // ['linux-aarch64',. No impact on correctness; just a slightly weaker guarantee than documented.

Approval blockers: ubuntu-22.04-arm runner availability for this repo, libwebkit2gtk-4.1-dev on jammy/arm64, and Tauri appimage,deb bundle + xvfb smoke success have never been exercised. A workflow_dispatch of desktop-packaging-check.yml on this branch under dry_run: true would settle this before merge.

Cross-check: qwen-code-ci-bot identified the same three non-blocking observations (permanent re-mirror tolerance, test comment regex, unverified build). All three confirmed independently from the diff. No finding in their review that I cannot account for.

Reviewed with AI assistance.

Critical-only review at d8ffac7f — approving, with one pre-merge verification named

Base 76c3dc5b. Ten files, +252/-26: the two feed scripts, three workflows, two docs lines, and three test files. I read both manifest scripts, all three workflow diffs, and the call sites that decide whether the tolerance hatch can fire.

Historical blocking issues

None. No CHANGES_REQUESTED has ever been posted on this PR, and of twelve threads all twelve are Suggestions — six resolved, six open. Under a Critical-only scan the open six are not mine to adjudicate.

The two [Critical] labels at this head are not code findings

The bot's review opens with "[Critical] Blocking finding(s) follow" and then says of both items that they are "neither a defect in the diff": one is a triage-stage gate that fires because the PR touches the release pipeline and desktop-latest.json is a contract the shipped updater consumes, and the other records that chiga0's review reports "No confirmed blocking findings" while withholding approval pending verification that the arm64 leg can build. I am treating them as what they are — an unexercised-infrastructure gate — and addressing that below rather than as a code defect.

My scan

The ambiguity the matrix row would otherwise create is closed on every side that selects a Linux artifact. The updater feed's linux-x86_64 row goes from /\.AppImage$/i to /_amd64\.AppImage$/i and a new linux-aarch64 row matches /_aarch64\.AppImage$/i, so with two Linux AppImages present each pattern resolves to exactly one file instead of the matches.length !== 1 throw that an extension-only match would produce. The Electron bridge is pinned the same way twice over: create-electron-bridge-manifest.mjs narrows its linux pattern to /_amd64\.AppImage$/i, and desktop-release.yml's glob becomes release-assets/*_amd64.AppImage while keeping the -ne 1 count check, so the bridge cannot pick up the arm64 artifact or silently accept two. ci.yml's changed-file filter now lists both feed scripts, which is what makes test-release.js — the only test either script has — actually run when the bridge script changes.

The tolerance hatch cannot drop a platform that has an artifact. The guard is conjunctive at head:

if (matches.length === 0 && allowMissingPlatforms.has(platform)) { … return null; }
if (matches.length !== 1) { throw new Error(`Expected one updater artifact for ${platform}, found ${matches.length}…`); }

So the hatch fires only on genuine absence; a present-but-duplicated artifact still throws. The if (!artifact) continue; added to the platform loop sits before the signature check, so a tolerated-null platform does not go looking for null.sig. And the hatch is scoped at the call site rather than in the script: manifest_args=() by default, set to (--allow-missing-platform linux-aarch64) only when [ "$SOURCE" = 'release' ], i.e. only when re-mirroring an already-published release. The fresh-build publish path passes no such flag, so a leg that failed to upload still fails the release instead of being published as missing. That is the right split, and the "${manifest_args[@]}" expansion is present on the invocation.

The new matrix row is the conservative one. ubuntu-22.04-arm rather than 24.04 keeps both Linux artifacts on a single glibc floor of 2.35, so the arm64 build cannot end up requiring 2.39 and refusing to start on the Ubuntu 22.04 and Debian 12 arm64 systems the x64 artifact still supports.

The repeat-accumulation in parseArguments is not reachable with a bad value today. values[name] = values[name] === undefined ? value : \${values[name]},${value}`applies to every option, so a duplicated single-valued flag would comma-join into the signed feed — the concern R1-1's follow-up raises. I checked both invocations: the mirror step passes--assets, --repository, --tag, --version, --base-url, --output` once each plus the optional hatch, and no caller duplicates a flag. It is a latent sharp edge in a shared parser rather than a defect at this head, and correctly filed as a Suggestion.

No Critical found.

The one thing I would verify before merge, and cannot from here

The arm64 leg has never been exercised: ubuntu-22.04-arm availability for this repo, libwebkit2gtk-4.1-dev on jammy/arm64, and a successful Tauri appimage,deb bundle with the xvfb smoke test are all unconfirmed, and this PR's own checks skip the desktop packaging lanes. Nothing in the diff can prove those, and I am not going to pretend otherwise. The reassuring part is the failure direction: if the leg cannot build, the leg fails and publish fails loudly, and the strict fresh-build path means a missing artifact cannot be published as an omitted feed key. A workflow_dispatch of the packaging check on this branch under dry_run: true would settle it, which is what chiga0 asked for and why that review withholds approval. My approval is about the code, not a claim that the build is proven — the maintainer's verification gate still stands and is a reasonable one.

CI

Clean at this head: 13 checks pass, zero failures, nothing pending. The three test files this PR adds or extends — the matrix↔feed parity check in test-release.js, the isolation assertion, and the OSS-workflow assertions — are what carry the invariants above.

Round 2 re-review at head d8ffac7f, base 76c3dc5b.

Prior-round finding status (round 1 at 9b920a22):

Incremental review (cfa6962d, d8ffac7f):

Two commits since round 1. cfa6962d closes round-1 qwen-code-ci-bot follow-ups; d8ffac7f corrects the comment raised in my prior review. Both are clean: no new logic, no new invariants introduced.

No new blocking findings.

Approval blockers:

Arm64 build execution remains unverified — structural, outside reviewer reach, as noted in round 1. ubuntu-22.04-arm runner availability, libwebkit2gtk-4.1-dev on jammy/arm64, and Tauri appimage,deb + xvfb smoke have not been exercised on this branch. A workflow_dispatch of the desktop-packaging-check workflow under dry_run: true remains the path to settle this before merge.

Cross-check (round 2):

The qwen-code-ci-bot round-2 "Critical" comment flags my round-1 approval blockers as unresolved. Correct — the arm64 execution gap is still open. That is a structural coverage gap, not a code defect in the diff; the code logic reviewed is sound.

Reviewed with AI assistance.

Round 3 re-review at head 95fe885 / base 0a136f89.

Prior-round finding status (round 2 at d8ffac7f, base 76c3dc5b):

Suggestions addressed since round 2:

All six qwen-code-ci-bot round-1 suggestions have been applied:

• R1-1 (multi-valued option comma/repeated-flag divergence): fixed in cfa6962d
• R1-2 (warning annotation absent on tolerant run): fixed in 217ceea5
• R1-3 (CI changed-file filter missing create-electron-bridge-manifest.mjs): fixed
• R1-4 (strictness split containment not pinned): fixed in 900863e7
• R1-5 (runManifest helper coverage): fixed in cfa6962d
• R1-6 (fresh-build path not covered by strictness test): fixed in 900863e7

Incremental commits reviewed:

217ceea5 — moves the ::warning:: annotation to after the feed is written. The test (doesNotMatch(stdout, /::warning::/) on a refused run) verifies a failed run emits no spurious annotation. Correct. ✓

900863e7 — adds desktop-oss-workflow.test.js tests pinning the strictness split by containment: the whole manifest_args=() if ... then ... fi block must appear in order, and the publish job's manifest step must not contain --allow-missing-platform. These are the critical anti-regression anchors for the whole tolerance mechanism. ✓

Merge commits 52ea4b5b, 95fe885 (base updates from main): no new logic, no conflicts with PR changes. ✓

No new blocking findings.

Approval:

The round-1 and round-2 structural disclosure — arm64 build never executed — is resolved at process level: desktop-packaging-check.yml runs daily with dry_run: true, exercising the new leg (build, artifact-collection, xvfb smoke) before any release runs. Code review confirms the structural pieces are correct: runner label ubuntu-22.04-arm is GA; glibc 2.35 floor is shared with x64; libwebkit2gtk-4.1-dev, AppRun-aarch64, linuxdeploy-aarch64 all exist upstream. Another maintainer (qqqys) reviewed and approved independently. Code review is complete.

Scope: All 10 changed files reviewed across 3 rounds. Incremental range this round: 217ceea5–95fe885 (2 logic commits + 2 merges).

Not covered: arm64 release build execution (inherently outside reviewer reach; desktop-packaging-check.yml daily dry-run is the verification path).

Reviewed with AI assistance.

Approving at 95fe8854. I reviewed the original change at 9b920a22 and have now reviewed the four substantive commits since.

The original change holds up. Narrowing the AppImage match from /\.AppImage$/i to /_amd64\.AppImage$/i plus a new /_aarch64\.AppImage$/i is required, not cosmetic — Tauri's AppImage arch tokens are _amd64/_aarch64 while the sibling .deb uses Debian's _amd64/_arm64, so extension-only matching is ambiguous once a second Linux leg exists. ubuntu-22.04-arm rather than 24.04 keeps both Linux legs on a glibc 2.35 floor; an arm64 artifact built on 24.04 would need 2.39 and refuse to start on the Ubuntu 22.04 / Debian 12 arm64 that the x64 artifact still supports. And narrowing the Electron-bridge glob to release-assets/*_amd64.AppImage is the easiest thing to have missed: the existing [ "${#linux_appimages[@]}" -ne 1 ] guard would have failed on two matches and taken the bridge path down with it.

cfa6962d closes the observability gap I raised on the earlier head — a tolerated-missing platform was silently omitted from the feed — and fixes a real CI routing hole beside it: create-electron-bridge-manifest.mjs was absent from the changed-files filter, so editing the bridge manifest never triggered scripts/test-release.js, which is the only test either script has. Emitting the annotation on stdout rather than stderr is correct and the reason is recorded: GitHub parses workflow commands from stdout only, and stderr has to stay clean for the thrown error the tests match on.

217ceea5 corrects two things in its predecessor, both sharply:

• The annotation moved out of selectArtifact to after fs.writeFileSync(options.output, …), collected via droppedPlatforms. Inside the selector it would also fire on runs that later throw and write nothing, annotating a feed that never existed — the message claims "publishing the feed without it", which is only true once the write has happened.
• Repeat-flag accumulation was narrowed to allow-missing-platform alone. Accumulating every option would comma-join a duplicated single-valued flag into the published, signed feed: --version a --version a yields a version no updater client can parse, and --output f --output f writes a file named f,f so no feed exists at all — both at exit status 0. I read the final parseArguments at this head and confirmed accumulation is scoped to multiValueOptions with last-wins preserved for everything else.

The test added at 900863e7 and the earlier testReleaseMatrixCoversUpdaterPlatforms are the reason this is safe to land: the matrix↔manifest cross-check is keyed on the [platform, selectArtifact( entry shape, so a commented-out entry stops counting as published, and assert.notEqual(missingLeg.status, 0) keeps the fresh-build path strict. Without that negative control the whole tolerance mechanism could degrade into "never fail" and stay green.

CI is green at this head: Test (ubuntu-latest, Node 22.x), Lint & Static (ubuntu-latest, Node 22.x) and Integration Tests (no-AK, No Sandbox) all passed with nothing failing across the run.

None of the touched paths (.github/scripts/, .github/workflows/ci.yml, packages/desktop/, scripts/tests/, docs/) are covered by CODEOWNERS, so no code-owner approval is required.