Repository navigation
ci(publish): skip publish when the version is already on the registry - #54
Merged
Merged
Conversation
A release-triggered run and a workflow_dispatch run can land on the same version. 0.4.0 was published by dispatch and tagged afterwards, so the release event replayed the job against a version already on the registry. npm answers E403 there, which reads like an auth failure and is not one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
0.4.0is on npm, published by Trusted Publishing from aworkflow_dispatchrun (#44 is closed with the root cause). The GitHub releases page still showsv0.3.0as latest, so the repo needs av0.4.0tag — but creating one fires this workflow throughon: release: [created], against a version already on the registry. npm answers:which looks like the auth failures this workflow has spent six runs eliminating, and isn't one.
Change
One step before
Publish, reading the registry for the version inpackage.json:skip=true, emit a::notice::, andPublishis skipped byif:Publishing behaviour is unchanged on the path that matters: a genuinely new version still goes out, still over OIDC, still with provenance. Only the redundant replay is skipped.
Why not just drop the
releasetriggerTagging a release is the natural way to cut one, and dispatch is the escape hatch that got
0.4.0out. Keeping both and making the job idempotent means the tag can be created at any time, before or after the publish, without the order mattering.Verification
CHANGELOG.mdis untouched: it records package behaviour per release, and this changes none. The guard is exercised by thev0.4.0release created right after this merges — the run should go green withPublishskipped.🤖 Generated with Claude Code