ci(release): stop publishing packages from inside the build matrix

[PathGao]

Problem

Four things went wrong around the v2.7.2 release. They are not four bugs — they share two causes.

An irreversible side effect placed before the decision it depends on. choco push and snapcraft push ran inside build.yml's platform matrix. Chocolatey's markpad-app 2.7.2 was published at 15:37 UTC on 2026-08-07 by run 31192564528 — a run that then failed on Linux and produced no release. The release users actually got came out of a different run three hours later. A Chocolatey version cannot be un-pushed.

A failure configured not to be one. Both pushes carried continue-on-error: true. The snap build has failed since v2.6.11:

Environment validation failed for part 'markpad': 'rustup' not found and part
'markpad' does not depend on a part named 'rust-deps' that would satisfy the
dependency.

That line is from the successful 2.7.2 run. The job reported success for three months and six versions while the Snap Store went on serving 2.6.11 (api.snapcraft.io, rev 15, 2026-06-03) and every release told people to sudo snap install markpad. Nobody reported it, because from the outside it looks like there is nothing to report — snapd checks for updates daily and tells those users they are current.

And the AppImage strip step failed in two of the three v2.7.2 release attempts (runs 31192564528, 31204367106), once on a stray -k and once on signing env vars, in a heredoc that can only be exercised by cutting a release.

Changes

Package managers publish after the release, not during the build — new publish-packages.yml, triggered by release: published, which is a human clicking Publish on a draft whose assets they have checked (RELEASING.md step 6). Two independent jobs, neither swallowing a failure. Also takes workflow_dispatch with a tag, so the snap and Chocolatey halves can be exercised against an existing release without cutting a new one — neither is reachable from a pull request otherwise.

The Chocolatey package now wraps the release's own Markpad_<version>_x64.exe instead of a second build. VERIFICATION.txt promised "copied directly" from a build; a rebuild from the same commit is not guaranteed to be the same bytes. It now describes what actually happens and carries the SHA256 and the exact URL, which is what a Chocolatey moderator can check.

The snap can find rustup — a rust-deps part, which is the one place other than PATH that snapcraft's rust plugin looks. The name comes from snapcraft, so it is asserted literally in the tests.

The AppImage strip is scripts/strip-appimage.sh — runnable against any downloaded AppImage, no signing key needed (signing stays in the workflow, which is what keeps the script runnable). It now verifies the repacked artifact rather than the AppDir: appimagetool packing the wrong directory would pass the weaker check. The excludelist has one home instead of two.

Worth being explicit about why the check is shaped that way: a CI smoke test cannot catch this defect. The runner's Mesa is the one the libraries were copied from, so nothing mismatches there and the AppImage starts fine — #498 had to be found by a user on Arch. "These libraries are absent" is the only property that can be checked before a release.

@tauri-apps/cli floored at ^2.11.4 — the lockfile resolved ^2 to 2.9.6, which predates the TAURI_SIGNING_* names, so the re-sign step had to spell the same secret the deprecated way while tauri build used the current one. 2.11.4 also fixes the AppImage bundler writing absolute symlinks for .desktop and .DirIcon — the same artifact this repacks. Both halves of the case are @PathGao's, in #497.

Verification

Measured, not assumed:

TAURI_SIGNING_PRIVATE_KEY + _PASSWORD on 2.11.4	writes the .sig
the same names on 2.9.6	Unable to find the private key (#497)
npm test	948 pass
npm run check	674 files, 0 errors
bash -n scripts/strip-appimage.sh, YAML parse of all three changed files	clean

Seven assertions added to scripts/releaseWorkflow.test.ts, each holding a property rather than a step name — the build matrix has no choco push / snapcraft push; publishing triggers only on release: published; no continue-on-error in either file; rust-deps exists and is depended on; the strip is a script and the excludelist is not duplicated; the verification runs after the repack; the CLI floor is high enough for the env vars the workflow uses.

What cannot be verified from a pull request, and how to close it: snapcraft needs LXD and store credentials, and the strip needs a Linux runner with the signing secret. After merging, run Publish Packages by hand against v2.7.2 — that exercises the snap fix end to end (including the store push) without cutting a release. If it goes green, the next release is the first one in six where the snap is real.

Not in this PR

Whether Markpad should keep the snap at all, plus code signing on macOS and Windows and the Linux distribution surface — #562.

🤖 Generated with Claude Code