Attach the tarballs before the Release publishes, because published means frozen - #166
Conversation
…eans frozen The first real next publish reached the Release step and failed there: this repo's releases are immutable, so gh release create published v8.0.0-rc.1 and the follow-up asset upload was refused with HTTP 422. The step now creates the Release as a draft with the smoked tarballs already attached, then publishes it through the API by the draft's id (a draft's tag does not exist yet, so gh cannot address it by tag). A rerun that finds the Release already published reports there is nothing to repair and succeeds, instead of failing the run after a complete npm publish. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
…r path Operator ruling 2026-08-12: cosmetic, not immediate. npm is healthy; only the GitHub Release page is missing its tarballs, permanently, because it published before the upload and releases are immutable. The repair steps (merge #165, attempt deletion, re-dispatch) are in the entry for whoever picks it up. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io>
|
Warning Review limit reached
Next review available in: 54 minutes You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
commit: |
Records only — no code. Follows the S3 close-out precedent (#157). ## What this records The S7 contract's seven acceptance items verified against source, merged PRs (#164, #166), two dry-run dispatches, and the registry: `@prisma/cli@8.0.0-rc.1` and `@prisma/cli-engine@8.0.0-rc.1` are live under `next`, `latest` untouched — the project DoD's artifact exists, published by the operator's own action. The Close-out section in `specs/s7-release.md` records the evidence per acceptance item, the two incidents from the first real publish (npm's trusted publisher still naming the deleted `publish-cli.yml`; the immutable Release freezing assetless before its upload) with their dispositions, and the one deliberately amended item: "Release with tarballs attached" holds from #166 onward, not for `v8.0.0-rc.1` itself. `plan.md` marks the slice closed. `deferred.md` gains the offered-but-undecided publish-script extraction. ## Out of scope here The S5 cutover (brief in #167, dispatched elsewhere), S2d and S6 (both dispatched elsewhere), S9. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Signed-off-by: willbot <w.a.madden+machine@gmail.com> Signed-off-by: Will Madden <madden@prisma.io> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
2 participants
Replaces #165, which showed the whole already-merged S7 diff because #164 was squash-merged out from under its branch. Content here is exactly the two new commits.
The grounding example
The first real
nextpublish (run 31618278670) shipped both packages to npm and then failed its final step:v8.0.0-rc.1exists, marked pre-release — with no tarballs attached, and none can ever be attached now.The decision
This repo's releases are immutable: publishing freezes assets and tag. So the Release step now creates the Release as a draft with the smoked tarballs already attached, then publishes it through the API by the draft's id — assets first, publish second, the order GitHub's own docs recommend. A draft's tag does not exist yet, so
gh release edit <tag>cannot address it; the id lookup handles that. A rerun that finds the Release already published logs that there is nothing to repair and succeeds, instead of failing a run whose npm publish completed.v8.0.0-rc.1itself stays assetless — immutability cuts both ways. Its repair path (cosmetic, deferred by operator ruling) is recorded indeferred.md, which this PR also updates.Alternatives considered
gh release createwithout--draft— what the code did; gh creates the release published and uploads after, which immutability rejects.deferred.md.🤖 Generated with Claude Code