feat: mark staged publishes as staged in GH release + publish finalize#147
Open
theoephraim wants to merge 9 commits into
Open
feat: mark staged publishes as staged in GH release + publish finalize#147theoephraim wants to merge 9 commits into
publish finalize#147theoephraim wants to merge 9 commits into
Conversation
…nalize` With npmStaged, `npm stage publish` leaves the package staged (not live), but bumpy treated it as published — marking the release target success with a dead npmjs.com link and finalizing the draft (firing release: published) before any approval. Now a staged publish is routed to PublishResult.staged (with the stage id parsed from `npm stage publish --json`), the release target is marked 🟡 staged, and the release stays a draft. A CI re-run treats staged as handled so it never re-stages. Adds `bumpy publish finalize [name@version]`: an idempotent reconcile that probes the registry and, once a staged version is live, flips it to success + real URL and publishes the release (firing release: published). Wired up via finalize.yaml with three triggers (repository_dispatch, schedule, workflow_dispatch).
|
The changes in this PR will be included in the next version bump.
|
…ze, manual + cron paths
…(batches are the norm)
…et when multi-target lands)
…ess) A staged tarball is already committed to the registry from the tagged SHA, so a publish re-run while awaiting approval must not move the tag to HEAD — that would point the release at a different commit than the artifact was built from.
…ailed (fix-forward keeps tracking HEAD)
npm exposes no public 'rejected' signal (a rejected stage is indistinguishable from a pending one via npm info), and the finalize job is credential-free, so bumpy can't auto-detect a rejection. After `npm stage reject`, run `bumpy publish reopen <name@version>`: it flips the staged target back to failed, which rejoins the fix-forward path — the tag un-freezes and the next publish re-stages. Abandon instead by not reopening (the next version supersedes the draft). Adds the command + CLI wiring, tests, and docs (cli.md, configuration.md, github-actions.md rejection subsection).
…taged package Closes the discoverability gap for non-stageflight users: after rejecting on npm and re-running publish, the skip is the wall they hit — now it names the reopen escape hatch inline.
…geflight), + gh release delete + abandon options
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.
Problem
With
npmStaged: true,npm stage publishleaves the package staged (awaiting 2FA approval), not live. But bumpy treated the staged result like a normal publish:npmjs.com/.../v/xlink that 404s until approval,release: published+ downstream workflows) before the package was actually out.This repo itself runs
npmStaged: true, so it was hitting this on every release.Fix
Honest staged marking
PublishResult.stagedbucket, with the stage id parsed fromnpm stage publish --json.'staged'target status renders 🟡 npm — staged, awaiting approval (no dead link); the stage id + timestamp are stored in the release metadata.release: published.stagedtargets as handled, so it never re-stages the same version.noStage) — they're ephemeral dist-tag previews that must be immediately installable.bumpy publish finalize [name@version](new)release: published). Still-staged versions are left untouched.ghis available — not CI-specific.Finalize workflow (
.github/workflows/finalize.yaml) — one command, three triggers:repository_dispatch(bumpy-finalize,client_payload.tag) — for approval tooling to fire post-approval,schedule— self-healing safety net,workflow_dispatch— manual / npm-UI-approval path.Needs only
contents: write— no npm or OIDC credentials.Docs
docs/configuration.md— staged lifecycledocs/github-actions.md— new "Staged publishing (finalize workflow)" section + dispatch payload contractdocs/cli.md—bumpy publish finalizeTests
416 pass (added coverage for
parseStageId, staged routing,noStage, and the staged release-body rendering). Lint/format/typecheck clean.