Use stage releases - #18
Conversation
|
Warning Review limit reached
Next review available in: 7 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: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (8)
📝 WalkthroughWalkthroughThe release tooling adds private contract-version planning and finalization. The reusable workflow submits packages to npm in staged mode by default or publishes them directly. GitHub release notes identify published and staged packages. ChangesRelease pipeline updates
Estimated code review effort: 4 (Complex) | ~60 minutes Sequence Diagram(s)sequenceDiagram
participant SharedReleaseWorkflow
participant ContractVersionCommand
participant NpmPublishingMode
participant Npm
participant GithubReleases
SharedReleaseWorkflow->>ContractVersionCommand: prepare contract version
ContractVersionCommand->>SharedReleaseWorkflow: persist version plan
SharedReleaseWorkflow->>NpmPublishingMode: classify workspace packages
NpmPublishingMode->>Npm: check package existence
SharedReleaseWorkflow->>Npm: stage or publish package groups
SharedReleaseWorkflow->>GithubReleases: pass published and staged summaries
GithubReleases->>SharedReleaseWorkflow: generate state-specific release notes
Possibly related PRs
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches 💡 1🛠️ Fix failing CI checks 💡
📝 Generate docstrings
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 |
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows-examples/README.md:
- Around line 48-52: Update the shared-release workflow summary in README.md to
describe both submission paths: staged publishing via pnpm stage publish when
staged-publishing is true, and direct pnpm publish when it is false. Make the
maintainer review and 2FA requirement explicitly conditional on staged
publishing, while preserving the existing release, tagging, and npm availability
details.
In @.github/workflows/shared-release.yml:
- Around line 235-241: Remove the NODE_AUTH_TOKEN environment variable and its
NPM_TOKEN reference from the “Stage packages on npm” step when
inputs.staged-publishing is enabled, so pnpm stage publish uses only the
stage-only OIDC trusted publisher. Do not alter authentication for other publish
steps; only retain a token here if package-level token restrictions explicitly
prevent direct publishing.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: e7d4a095-6415-451e-af69-7d140c4be9e2
📒 Files selected for processing (17)
.changeset/hip-memes-rhyme.md.github/scripts/gha.mjs.github/workflows-examples/README.md.github/workflows-examples/release.yml.github/workflows/release.yml.github/workflows/shared-release.ymlinternal/gha/README.mdinternal/gha/src/commands/contract-version.test.tsinternal/gha/src/commands/contract-version.tsinternal/gha/src/commands/github-releases.tsinternal/gha/src/commands/index.test.tsinternal/gha/src/commands/index.tsinternal/gha/src/contract-version.test.tsinternal/gha/src/contract-version.tsinternal/gha/src/github-releases.test.tsinternal/gha/src/github-releases.tsinternal/gha/src/workflows.test.ts
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
internal/gha/src/github-releases.ts (1)
140-151: 🗄️ Data Integrity & Integration | 🟡 Minor | ⚡ Quick winTags are created for staged versions before approval.
The
releaseslist combines published and staged packages, and every entry receives a git tag at line 150. A maintainer can reject a staged version during the npm approval step. The repository then keeps a tag for a version that never becomes available on npm, and a later re-release of the same version cannot reuse that tag. Confirm that this is the intended behavior, or defer tag creation for staged packages until approval.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@internal/gha/src/github-releases.ts` around lines 140 - 151, Update the release flow around createTag so staged packages are not tagged before npm approval; create tags only for published releases, or move staged-package tagging into the post-approval path. Preserve tagging for approved/published versions and ensure rejected staged versions do not leave reusable version tags behind.
🧹 Nitpick comments (4)
internal/gha/src/commands/npm-publishing-mode.ts (2)
60-69: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winReuse the parsed boolean for the output flags.
Lines 63 and 64 re-derive the staged-publishing decision from the raw string, although
parseBooleanalready produced that value at line 36. The two code paths can diverge if the parser later accepts more inputs, for example"1"or"TRUE".♻️ Proposed refactor
+ const stagedPublishing = parseBoolean(rawStagedPublishing); const plan = await planNpmPublishing( parseWorkspacePackages(readFileSync(workspacePath, "utf8")), - parseBoolean(rawStagedPublishing), + stagedPublishing, @@ - `direct=${rawStagedPublishing === "false" || plan.firstReleasePackages.length > 0}`, - `direct_all=${rawStagedPublishing === "false"}`, + `direct=${!stagedPublishing || plan.firstReleasePackages.length > 0}`, + `direct_all=${!stagedPublishing}`,🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@internal/gha/src/commands/npm-publishing-mode.ts` around lines 60 - 69, Update the output flag construction in the publishing command to reuse the boolean produced by parseBoolean instead of comparing rawStagedPublishing to the string "false"; apply the parsed value consistently for direct and direct_all while preserving the first-release package logic for direct.
37-41: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winAdd a timeout to the registry lookup.
npm-publishing-moderuns with the caller-suppliednode-versioninput, which can be an LTS older than Node 17 whereAbortSignal.timeoutis unavailable; use an explicitAbortControllertimeout instead so the release step fails quickly when the registry stops responding.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@internal/gha/src/commands/npm-publishing-mode.ts` around lines 37 - 41, Add an explicit AbortController-based timeout to the fetch callback inside packageExistsOnRegistry, avoiding AbortSignal.timeout for compatibility with older Node versions. Start a timer that aborts the request after the chosen timeout and clear it when the fetch completes, while preserving the existing headers and registry lookup behavior.internal/gha/src/npm-publishing.test.ts (1)
46-57: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winAdd a case for disabled staging with an existing package.
The current tests never cover
stagedPublishing = falsecombined with an already published package. That path must producemode: "direct"with emptyfirstReleasePackages, which is what drives thedirect_allworkflow output.♻️ Proposed test
+test("uses direct publishing for existing packages when staging is disabled", async () => { + const packageExists = vi.fn(async () => true); + + await expect( + planNpmPublishing([workspacePackage("public")], false, packageExists), + ).resolves.toEqual({ + mode: "direct", + firstReleasePackages: [], + stagedPackages: [], + }); +});🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@internal/gha/src/npm-publishing.test.ts` around lines 46 - 57, Add a test alongside the existing explicit regular-publishing case that calls planNpmPublishing with stagedPublishing false and a packageExists mock returning true. Assert it resolves to mode "direct" with empty firstReleasePackages and the existing package listed in stagedPackages, and verify packageExists is called once with the package name..github/workflows/shared-release.yml (1)
260-296: 🩺 Stability & Availability | 🔵 Trivial | ⚡ Quick winPublishing runs no verification that the summary file exists.
Both steps run
mv pnpm-publish-summary.jsonright after the publish command. Ifpnpmwrites the summary to a different location, or writes nothing when no package matches the filters,mvfails and the job stops after packages were already submitted to npm. Consider guarding the move.♻️ Proposed guard
pnpm publish -r "${filters[@]}" --access public --no-git-checks --report-summary - mv pnpm-publish-summary.json "${RUNNER_TEMP}/published-summary.json" + if [ -f pnpm-publish-summary.json ]; then + mv pnpm-publish-summary.json "${RUNNER_TEMP}/published-summary.json" + fi🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/shared-release.yml around lines 260 - 296, Guard the summary-file moves in the “Publish packages to npm directly” and “Stage packages on npm” steps by checking that pnpm-publish-summary.json exists before moving it to the corresponding runner-temp destination; preserve successful publishing when no summary is produced.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@internal/gha/src/github-releases.ts`:
- Around line 140-151: Update the release flow around createTag so staged
packages are not tagged before npm approval; create tags only for published
releases, or move staged-package tagging into the post-approval path. Preserve
tagging for approved/published versions and ensure rejected staged versions do
not leave reusable version tags behind.
---
Nitpick comments:
In @.github/workflows/shared-release.yml:
- Around line 260-296: Guard the summary-file moves in the “Publish packages to
npm directly” and “Stage packages on npm” steps by checking that
pnpm-publish-summary.json exists before moving it to the corresponding
runner-temp destination; preserve successful publishing when no summary is
produced.
In `@internal/gha/src/commands/npm-publishing-mode.ts`:
- Around line 60-69: Update the output flag construction in the publishing
command to reuse the boolean produced by parseBoolean instead of comparing
rawStagedPublishing to the string "false"; apply the parsed value consistently
for direct and direct_all while preserving the first-release package logic for
direct.
- Around line 37-41: Add an explicit AbortController-based timeout to the fetch
callback inside packageExistsOnRegistry, avoiding AbortSignal.timeout for
compatibility with older Node versions. Start a timer that aborts the request
after the chosen timeout and clear it when the fetch completes, while preserving
the existing headers and registry lookup behavior.
In `@internal/gha/src/npm-publishing.test.ts`:
- Around line 46-57: Add a test alongside the existing explicit
regular-publishing case that calls planNpmPublishing with stagedPublishing false
and a packageExists mock returning true. Assert it resolves to mode "direct"
with empty firstReleasePackages and the existing package listed in
stagedPackages, and verify packageExists is called once with the package name.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 165d0c2b-c615-4742-bf06-a000d3e92201
📒 Files selected for processing (14)
.changeset/hip-memes-rhyme.md.github/scripts/gha.mjs.github/workflows-examples/README.md.github/workflows-examples/release.yml.github/workflows/shared-release.ymlinternal/gha/src/commands/github-releases.tsinternal/gha/src/commands/index.test.tsinternal/gha/src/commands/index.tsinternal/gha/src/commands/npm-publishing-mode.tsinternal/gha/src/github-releases.test.tsinternal/gha/src/github-releases.tsinternal/gha/src/npm-publishing.test.tsinternal/gha/src/npm-publishing.tsinternal/gha/src/workflows.test.ts
🚧 Files skipped from review as they are similar to previous changes (4)
- internal/gha/src/commands/index.test.ts
- .github/workflows-examples/release.yml
- .changeset/hip-memes-rhyme.md
- .github/workflows-examples/README.md
|
@coderabbitai review |
✅ Action performedReview finished.
|
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@internal/gha/README.md`:
- Line 24: Add the text language identifier to the fenced code block in the
README so the CLI syntax block uses a language-tagged fence and satisfies
markdownlint MD040.
🪄 Autofix
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Repository UI
Review profile: CHILL
Plan: Pro Plus
Run ID: 0351218d-f750-4e3c-8003-f46ce0793ee3
📒 Files selected for processing (14)
.changeset/hip-memes-rhyme.md.github/scripts/gha.mjs.github/workflows-examples/README.md.github/workflows/shared-release.ymlinternal/gha/README.mdinternal/gha/src/commands/npm-publishing-mode.tsinternal/gha/src/github-releases.test.tsinternal/gha/src/github-releases.tsinternal/gha/src/github.test.tsinternal/gha/src/github.tsinternal/gha/src/npm-publishing.test.tsinternal/gha/src/npm-publishing.tsinternal/gha/src/release-tags.tsinternal/gha/src/workflows.test.ts
🚧 Files skipped from review as they are similar to previous changes (7)
- internal/gha/src/github-releases.test.ts
- .changeset/hip-memes-rhyme.md
- .github/workflows-examples/README.md
- internal/gha/src/github-releases.ts
- .github/workflows/shared-release.yml
- internal/gha/src/workflows.test.ts
- .github/scripts/gha.mjs
2 participants
This pull request updates the release automation to use npm staged publishing by default, with an option for consumers to opt into direct publishing. It also introduces support for advancing a private shared-workflow contract version during release pull requests and updates documentation and workflow files to reflect these changes.
Release process improvements:
Default behavior is now npm staged publishing; maintainers must approve staged packages with 2FA before they are available from npm. Consumers can opt out by setting
staged-publishing: falsefor direct publishing. (.changeset/hip-memes-rhyme.md,.github/workflows-examples/README.md,.github/workflows-examples/release.yml,.github/workflows/shared-release.yml, [1] [2] [3] [4] [5] [6]The release scripts and workflows now advance the version of a private contract package (e.g., internal workflow/tooling contracts) if specified via the new
contract-version-packageinput. (.github/workflows/shared-release.yml,.github/workflows/release.yml, [1] [2]Script and workflow changes:
.github/scripts/gha.mjsscript introduces new logic for contract version management, staged publishing, and improved release note generation, including clear messaging when packages are staged vs. published. (.github/scripts/gha.mjs, [1] [2] [3] [4] [5] [6] [7]Documentation updates:
.github/workflows-examples/README.md, [1] [2].github/workflows/shared-release.yml, [1];.github/workflows-examples/release.yml, [2]These changes modernize the release pipeline for improved security and flexibility, and make it easier for consumers to manage both staged and direct publishing workflows.