fix(release): retry an npm publish that a transient signing failure killed - #1568
fix(release): retry an npm publish that a transient signing failure killed#1568zfy0701 wants to merge 1 commit into
Conversation
…illed The release job publishes with npm OIDC trusted publishing, which implies a provenance attestation, which needs a signing certificate from Sigstore's Fulcio CA. That call answered `CA_CREATE_SIGNING_CERTIFICATE_ERROR ... (403) Forbidden` on v1.51.0-rc.2 and took the whole release down with it. Re-running the job cannot recover that: semantic-release pushes the tag and its channel note before publish plugins run, so the next run reads the release as already made, exits with no new version, and the package never reaches npm -- while the image built from the same commit embeds it. The retry therefore has to sit inside the publish command, and the publish is the retry unit because attestation and upload are one pnpm call. Three attempts, 20s and 40s apart. An attempt that uploaded before failing leaves the version on the registry, so a republish conflict counts as done -- matched on the message, since that answer is a 403 as well.
|
Review result: one blocking release-path issue.
All three The wrapper passed sent by |
1 participant
What broke
v1.51.0-rc.2was tagged but never published.pnpm publishfailed with[CA_CREATE_SIGNING_CERTIFICATE_ERROR] error creating signing certificate - (403) Forbiddenfrom Sigstore's Fulcio CA while building the provenance attestation. The release job
publishes through npm OIDC trusted publishing, which implies provenance, so every publish
depends on that CA answering.
Why the retry cannot live in the workflow
semantic-release pushes the git tag and its channel note before running publish plugins.
Re-running the job therefore finds the release already made, reports no new version, and
exits — the package never reaches npm, and image publication is skipped for want of a
version output. The retry has to sit inside the publish command, and the publish call is the
retry unit because pnpm attests and uploads in one step.
What changed
scripts/npm-publish-with-retry.shwraps thepnpm publishline that the daemon, CLI, andsetup publish scripts all shared: three attempts, 20s and 40s apart. An attempt that uploaded
before failing leaves the version on the registry, so a republish conflict counts as done —
matched on the message, because that answer is a 403 as well.
Note that
scriptsis part of the setup package's change-detection input set (it mirrors thecontrol-plane image inputs), so this commit alone makes setup publish on the next release —
which also closes the gap left by the failed one. The daemon and CLI input sets do not
include
scripts, so they are unaffected.Testing
Exercised the wrapper against a stubbed
pnpm: a transient failure retries and thensucceeds, a republish conflict short-circuits to success, and a permanent failure exhausts
the attempts and exits non-zero.
🤖 Generated with Claude Code