ci(release): decompose registry publishing into independently dispatchable per-registry workflows

[Mikola Lysenko (mikolalysenko)]

What

The crates.io, npm, PyPI, and RubyGems legs of release.yml move into their own workflows — publish-{cargo,npm,pypi,rubygems}.yml. A release is still one dispatch: release.yml (version gate → 14-target build → tag → GitHub release) then dispatches each leg at the release tag via scripts/dispatch-publish.sh and watches the dispatched run to completion, so the release run's job graph still reflects every registry's real outcome and "Re-run failed jobs" re-dispatches exactly the failed legs.

After a mid-release failure, any single registry can now also be retried standalone — Actions → Publish crates.io / npm / PyPI / RubyGems → Run workflow with the release version — without rebuilding anything: each leg checks out the v<version> tag, and npm/PyPI take the prebuilt binaries from the GitHub release's assets verified against SHA256SUMS (release-run dispatches additionally pin the sums file by digest; manual retries are integrity-only). This is exactly the v4.0.0 pain point: fixing a registry-side trusted publisher and re-publishing one ecosystem no longer touches the other three.

Why dispatch, not reusable workflows (uses:)

Verified against the registries' docs and source (warehouse, rubygems.org, crates.io) on 2026-08-21:

Registry	Publisher filename matched against	Publishers per package
crates.io	top-level (workflow_ref)	up to 5
npm	top-level (workflow_ref)	exactly 1
PyPI	job-defining file (job_workflow_ref) today; flip to top-level planned (warehouse #20083)	multiple
RubyGems	job-defining file (job_workflow_ref)	multiple

npm matches the top-level filename and allows one publisher per package, so a leg that is sometimes uses:-called (top-level = release.yml) and sometimes dispatched (top-level = its own file) can never be authorized for both paths. Dispatching makes every leg always the top-level workflow of its own run, so workflow_ref and job_workflow_ref both name the leg's file and one publisher registration per package covers everything on every registry — immune to the PyPI flip. workflow_dispatch events are a documented exception to GITHUB_TOKEN event suppression, so no PAT is needed.

Hardening (from the adversarial review)

• Each publish workflow serializes same-version runs via a concurrency group, so a duplicate dispatch (watcher timeout → re-run) waits and then no-ops on the idempotency probes instead of racing them; dispatch-publish.sh diagnoses a displaced-duplicate cancellation distinctly.
• The correlation poll tolerates transient gh run list failures and binds on headBranch == v<version> in addition to the distinct-id in the run name.
• The release run refuses to dispatch an unpinned npm/PyPI publish if the SHA256SUMS digest came out empty (fail closed).
• timeout-minutes: 45 on every leg bounds how long a wedged run can hold its concurrency group; watchers match.

One-time ops after merge (before the next release)

Re-register trusted publishers against the new filenames — table in docs/releasing.md § One-time registry setup:

• crates.io / PyPI / RubyGems: add publish-{cargo,pypi,rubygems}.yml publishers alongside the existing release.yml ones (all three allow multiples); delete the release.yml ones only after every pre-split run (v4.0.0 re-runs on run 32441686301) has fully landed.
• npm: single publisher per package → atomic cutover to publish-npm.yml once no pre-split npm job may need re-running (approving the already-staged v4.0.0 versions needs no OIDC; only re-staging does).

Review: ULTRACODE multi-agent pass (6 review dimensions → 17 raw findings → 2-vote adversarial verification → 13 confirmed, all fixed) plus a 3-lens verification pass over the fixes (4 residuals, all fixed). Registry claim semantics verified against pypi/warehouse, rubygems.org, and rust-lang/crates.io source plus official docs.

🤖 Generated with Claude Code

---

Note

High Risk
Rewires the entire multi-registry release path and OIDC trusted-publisher identity (workflow filenames, actions:write fan-out, npm/PyPI asset provenance). A misconfigured publisher cutover or dispatch correlation bug can block or mis-publish a release.

Overview
Release publishing is no longer inlined in release.yml. crates.io, npm, PyPI, and RubyGems each get a standalone workflow_dispatch workflow. A release is still one dispatch: after tag + GitHub release, release.yml fans out via scripts/dispatch-publish.sh and watches each run so the job graph still shows real registry outcomes.

Why dispatch, not uses:: trusted publishers key off workflow filename, and npm allows only one publisher per package. Dispatching makes every leg always the top-level workflow of its own file, covering both fan-out and manual retries without a PAT (workflow_dispatch is the GITHUB_TOKEN event-suppression exception).

Retry without rebuild: each leg checks out v<version>; npm/PyPI pull binaries from the GitHub release, verify SHA256SUMS, and (on the fan-out path) pin that sums file by digest. Same-version runs serialize; already-published/staged versions are skipped. Ops after merge: re-register OIDC publishers against the new filenames (npm cutover is atomic).

^{Reviewed by Cursor Bugbot for commit 6e8d7c6. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{Bugbot Autofix is ON. A cloud agent has been kicked off to fix the reported issue.}

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 6e8d7c6. Configure here.}

[cursor]

Watcher ignores successful run conclusion

Low Severity

When gh run watch returns non-zero, the script always exits 1 even after gh run view reports conclusion of success. A transient watch/API failure after the publish leg already succeeded makes the release fan-out job fail and can trigger an unnecessary re-dispatch.

 

^{Reviewed by Cursor Bugbot for commit 6e8d7c6. Configure here.}

[Mikola Lysenko (mikolalysenko)]

CI note: the test (macos-latest) failure here is a pre-existing flaky test unrelated to this PR (apply_lock orphaned-inode race test; this PR touches only workflows/shell/docs). It failed 3/3 re-runs in two distinct scheduler-race modes — diagnosed and fixed in #232. Once #232 merges, re-running the failed job here should go green.