fix(release): draft-then-promote releases; un-pin npm past sigstore bug

[willem445]

Summary

Two related hardening fixes to release.yml, both flagged from PR #272's review.

#275 — draft-then-promote. build is a 4-leg matrix uploading assets to one GitHub release. Previously that release was created public/non-draft (releaseDraft: false) the moment the first leg ran, so a partial failure (one leg fails after others already uploaded) left a public latest release missing assets — install.sh/install.ps1 resolve latest and hit 404s on the missing files.

Fix: build now creates the release as a draft (releaseDraft: true, tauri-action's native support). A new promote job (needs: build) flips it public with gh release edit --draft=false — and since fail-fast: false means a single failed leg fails the build job as a whole, promote is skipped whenever any leg fails, leaving the release stuck in draft rather than public-and-incomplete. latest can only ever resolve to a complete release.

publish-npm now depends on promote, not just build. Reasoning: GitHub does not serve release assets off a draft release to anonymous downloads, and the npm launcher (npx loomux-desktop) resolves those assets at runtime, not at publish time — so if publish-npm only waited on build, a user could npx loomux-desktop between npm-publish and the (manual/delayed) promotion and get a 404. Waiting on promote transitively waits on build too, so #221's ordering guarantee is preserved.

#186 — un-pin npm past the sigstore bug. npm/cli#9722 (npm 12.0.0 shipped without its bundled sigstore module, breaking provenance publish with MODULE_NOT_FOUND) is closed, but per the issue's standing instruction I verified the fix actually ships in a reachable version rather than trusting issue state alone:

• Fixed by npm/cli#9740 ("correct bundled sigstore from dev dependency conflict"), merged 2026-07-10.
• Released in npm 12.0.1 the same day.
• Verified directly: downloaded npm-12.0.1.tgz from the registry and confirmed node_modules/sigstore is present (5 files, matching the working 11.18.0 bundle) — not just reading the changelog.

Moved the pin from npm@^11 to npm@^12.0.1 — excludes the broken 12.0.0 specifically while tracking future 12.x patches, same style as the old range tracking 11.x patches.

Out of scope / follow-up

• If build fails and promote is skipped, the draft release is left behind for manual cleanup (or a retry) — no automated draft-deletion was requested by either issue, noting it here rather than silently expanding scope.
• OIDC trusted publishing (id-token: write, no NPM_TOKEN) is untouched.

Test plan

• actionlint (v1.7.7, prebuilt Windows binary) — clean, no findings.
• Hand-verified the new/changed run: shell blocks under bash -e semantics (actionlint skips shellcheck without it on PATH): both are single-line commands, no multi-line/heredoc pitfalls. Fixed one issue in review: the promote step originally interpolated ${{ github.ref_name }}/${{ github.repository }} directly into run: (classic Actions script-injection pattern for untrusted-ish tag names) — switched to the default env vars $GITHUB_REF_NAME/$GITHUB_REPOSITORY, matching the existing safe convention already used for VERSION in publish-npm.
• Real release run (draft creation, matrix upload, promote, npm publish end-to-end) — needs an actual tag push; left for the next release cut per repo convention (agents don't spawn real publishes).

Closes #275, Closes #186

[willem445]

Verdict: Approve — 2 non-blocking findings. The happy path and the common re-run-failed path are correct; the injection hardening is right; every npm/sigstore claim in the PR body checks out against primary sources. The two findings are rare, recoverable, and largely pre-existing upstream behavior — not release-blockers — but they mean the PR's "latest can only ever resolve to a complete release" guarantee is "almost always," not "always," so I'm documenting them for the human before the cut.

I verified the mechanics against source, not just the PR narrative:

• tauri-action create-release.ts — with releaseDraft: true it does not use getReleaseByTag (which 404s on drafts). It pages listReleases (drafts included) and matches by tag_name. So the four matrix legs do converge on one draft — provided the first leg's draft exists before later legs run their lookup. The check-then-create is not atomic.
• tauri-action upload-release-assets.ts — deletes any same-named existing asset, then re-uploads. So re-running one leg against an existing draft is idempotent (no double-upload/conflict).
• gh shared/fetch.go FetchRelease — runs the published lookup and a GraphQL draft-by-pending-tag lookup concurrently and takes whichever resolves. So gh release edit "$GITHUB_REF_NAME" --draft=false does find the draft tauri-action created (it sets tag_name on the draft). Promote's targeting is sound for the single-draft case.

What's correct (checked, not assumed)

#186 / npm pin — fully verified independently:

• npm/cli#9740 ("correct bundled sigstore from dev dependency conflict") is merged 2026-07-10.
• npm 12.0.1 published 2026-07-10, and is the current latest dist-tag.
• Pulled npm-12.0.1.tgz from the registry: node_modules/sigstore/ is present (5 files) — matches the PR body's claim exactly.
• npm install -g npm@^12.0.1 resolves to 12.0.1+, excludes the broken 12.0.0, and overrides whatever npm Node 22 bundles — so the pin is effective at the point that matters (the provenance npm publish). Good.

Injection hardening (item 5) — correct everywhere. The only run: block touching the tag is promote, and it uses $GITHUB_REF_NAME/$GITHUB_REPOSITORY (quoted), not ${{ }}. The remaining ${{ github.ref_name }} uses are in the build job's with: inputs (tagName, releaseName) — action inputs, not shell — so no substitution-into-shell remains. publish-npm already used $GITHUB_REF_NAME.

Permissions survive the re-wire. promote declares contents: write (needed for gh release edit; no checkout needed — gh is preinstalled, GH_TOKEN set). publish-npm keeps id-token: write + contents: read, so OIDC trusted publishing is untouched. needs: promote transitively preserves the #221 ordering.

Shell under bash -e (item 6, shellcheck caveat). Both ubuntu jobs run bash with set -eo pipefail. promote is a single quoted command — a non-zero exit (e.g. draft not found) correctly fails the job loudly. publish-npm's npm view guard sits in an if condition, so -e doesn't fire on the not-yet-published case — the idempotence guard from #272 is intact. GITHUB_REF_NAME is always set on a tag push. No unset-var or unpropagated-failure traps. (Note: I could not run actionlint locally — not installed in this worktree — so this is a hand-check; the PR's actionlint-clean claim is plausible given the YAML is well-formed.)

Full release walk-through

Happy path (git push of a v* tag): trigger → 4 build legs. Legs finish at very different wall-clock times (different OSes, staggered Rust compiles), so the first to reach tauri-action creates the single draft; the later three find it via listReleases and upload into it. All 4 green → build job green → promote runs → gh release edit <tag> --draft=false flips the one draft public → publish-npm runs, bumps version, guard sees it unpublished, npm publish. latest first resolves only after promote. ✅ Correct.

One leg fails (the common failure): fail-fast:false → other 3 upload, but build is red → promote and publish-npm are skipped → release stays a draft → latest never resolves to it. ✅ Exactly the intended safe direction, and re-runnable (see below).

Re-run failed jobs (common retry) — handled well: only the failed leg + skipped promote/publish-npm re-run. The failed leg finds the still-draft release and uploads (delete-then-re-upload → idempotent even if it had partially uploaded before failing). promote then flips the now-complete draft public; npm publishes. ✅

If promote itself fails after all builds succeed: release stays draft, latest unaffected — safe. Detectable (red promote job) and re-runnable (re-run just promote; gh release edit --draft=false on an already-correct draft is fine). ✅

promote succeeds / npm fails, then rerun: re-run publish-npm; the npm view guard skips if the version already published, else publishes. Release already public, unaffected. ✅

Finding 1 (non-blocking) — duplicate-draft matrix race weakens the "always complete" guarantee

create-release.ts's list-then-create is not atomic (upstream tauri-action #914, observed ~2–3 per 78 releases). If two legs race before either draft is visible to the other, you get two draft releases for the same tag, each with a subset of assets. All legs still exit 0, so build is green and promote runs. gh's draft lookup (GraphQL release(tagName:)) returns one of them — possibly the incomplete one — and flips that public. Result: the partial-public-latest failure #275 set out to prevent, reachable via the race, plus an orphan draft.

Why non-blocking: (a) it's pre-existing upstream behaviour of the matrix-without-releaseId pattern, neither introduced nor fixed here; (b) staggered build times make it rare in practice; (c) the PR is still a strict improvement over the old public-from-first-leg flow for the dominant single-leg-failure case. But the PR body / code comment claim latest can only ever be complete — that's overstated; please soften the wording. The robust fix (follow-up, not this PR) is tauri-action's own documented pattern: a separate create-release job that creates the draft once and emits releaseId, which the matrix legs consume — that removes the race and makes promote's target unambiguous.

Finding 2 (non-blocking) — "Re-run all jobs" after a successful release spawns a duplicate draft

Confirmed from create-release.ts: with releaseDraft: true, when a leg finds an existing release for the tag that is not a draft (i.e. already promoted to public), it logs "NOT a draft", breaks, treats it as not-found, and creates a fresh draft. So clicking "Re-run all jobs" on an already-published release: all 4 legs re-upload into a brand-new duplicate draft; then promote's gh release edit either no-ops on the existing public release or hits a 422 trying to publish a second release for the same tag (nondeterministic, depending on which concurrent lookup in FetchRelease wins) — leaving a stray fully-populated duplicate draft behind. npm is protected by its idempotence guard.

This is a behavioural regression vs. the old releaseDraft: false flow, where a re-run-all cleanly re-uploaded into the existing public release (idempotent). Non-blocking because it doesn't affect a fresh release cut and the original public release/latest survives (worst case is a red promote + manual draft cleanup), but it contradicts the re-run-safety framing and is worth a one-line caveat in the PR's "Out of scope" list (alongside the existing draft-cleanup note). The releaseId-job refactor in Finding 1 would also fix this.

Bottom line

Ship it for the imminent release — the fresh-tag happy path and the common retry path are correct and the npm fix is real. Just (1) soften the "only ever complete" wording to acknowledge the residual matrix race, and (2) add the re-run-all caveat. Both findings point at the same optional follow-up (separate create-release job emitting releaseId); neither should hold the release.