fix(release): make npm publish idempotent on stuck-release re-runs#224
Merged
Conversation
When a release gets stuck and is re-driven (e.g. the automated release-please → workflow_call → release.yml chain failed mid-publish and is re-run, or a tag-scheme migration leaves a version tagged-but-unpublished), `pnpm publish` hard-fails because the version already exists on npm. Add a preflight `npm view <name>@<version>` guard that skips the publish step when the registry already serves the exact version, emitting a ::notice:: instead of erroring. Makes the publish job safe to retry. Also documents the no-recovery-path trap in the trusted-publisher lesson: npm allows only ONE trusted publisher per package, so with only release-please.yml registered there is no working MANUAL publish recovery (both `gh release create` and `workflow_dispatch release.yml` carry release.yml as the OIDC entry → token-exchange 404). Recovery must go through the automated chain.
Merged
theagenticguy
pushed a commit
that referenced
this pull request
Jun 11, 2026
🤖 Automated release via release-please --- <details><summary>0.7.6</summary> ## [0.7.6](v0.7.5...v0.7.6) (2026-06-11) ### Bug Fixes * **release:** make npm publish idempotent on stuck-release re-runs ([#224](#224)) ([12e1c66](12e1c66)) </details> --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Merged
theagenticguy
pushed a commit
that referenced
this pull request
Jun 11, 2026
🤖 Automated release via release-please --- <details><summary>root: 0.8.6</summary> ## [0.8.6](root-v0.8.5...root-v0.8.6) (2026-06-11) ### Bug Fixes * **release:** collapse release-please to one published @opencodehub/cli component ([#222](#222)) ([ab749bd](ab749bd)) * **release:** make npm publish idempotent on stuck-release re-runs ([#224](#224)) ([12e1c66](12e1c66)) * **release:** restore two-component config + linked-versions to fix CLI starvation ([#227](#227)) ([f849f24](f849f24)) * **release:** set explicit empty component so the CLI release PR matches ([#226](#226)) ([4188b52](4188b52)) </details> <details><summary>cli: 0.8.6</summary> ## [0.8.6](cli-v0.7.4...cli-v0.8.6) (2026-06-11) ### Bug Fixes * **release:** restore two-component config + linked-versions to fix CLI starvation ([#227](#227)) ([f849f24](f849f24)) </details> --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.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
1 participant
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.
Context
Follow-up to the release-pipeline recovery (#222 collapsed to one published component). While unsticking the published CLI we hit a real fragility: a release that's tagged + GitHub-released but not yet published cannot be safely re-driven, because
pnpm publishhard-fails when the version already exists on npm.Change
Add a preflight idempotency guard to the
npm-publishjob:npm view <name>@<version>— if the registry already serves the exact version, skip the publish step (emit a::notice::) instead of erroring. Makes the publish job safe to retry, which is exactly what a stuck-release recovery needs.Also updates the trusted-publisher lesson with the no-recovery-path trap: npm allows only ONE trusted publisher per package, so with only
release-please.ymlregistered there is no working manual publish recovery (gh release createandworkflow_dispatch release.ymlboth carryrelease.ymlas the OIDC entry → token-exchange 404). Recovery must go through the automated chain — which is what this PR's merge will exercise.Validation intent
Merging this triggers release-please to open a 0.7.6 release PR. Merging that PR runs the automated
release-please.yml → workflow_call → release.ymlchain, whose OIDC entry (release-please.yml) matches the registered trusted publisher → publishes 0.7.6 to npm with provenance. This both lands the fix and proves the collapsed single-component release process end-to-end (npm was stuck at 0.7.4).CI-relevant only; no runtime/CLI behavior change.