fix(ci): read next-release version from release-please branch in rc-release#2232
Merged
Conversation
…elease main's .release-please-manifest.json holds the last released version, so the previous logic produced RC tags for the *current* release (e.g. wren-v0.3.0-rc.1 when 0.3.0 was already released and 0.4.0 was pending). The next-release version lives on the per-component release-please branch (release-please--branches--main--components--<component>). Read the manifest from there. If the branch is absent, there is no pending release for the component and the workflow now fails with a clear message instead of silently re-tagging the released version.
Contributor
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
WalkthroughRC base-version resolution now fetches the component-specific release-please branch and reads ChangesRC Version Manifest Resolution
Trusted NPM Publishing (publish-wren-core-wasm)
Sequence Diagram(s)sequenceDiagram
participant ReleaseWorkflow as Release-please workflow
participant GitRemote as Git remote (origin)
participant Runner as GH Actions runner
participant Python as Embedded Python snippet
participant NPMRegistry as npm registry
ReleaseWorkflow->>Runner: start rc-release job
Runner->>GitRemote: git ls-remote (verify branch) / git fetch
Runner->>GitRemote: git show .release-please-manifest.json@RELEASE_BRANCH
Runner->>Python: pass MANIFEST_JSON + COMPONENT
Python->>Runner: print BASE_VERSION
ReleaseWorkflow->>Runner: invoke publish-wren-core-wasm with id-token
Runner->>NPMRegistry: authenticate via ID token (trusted publishing)
Runner->>NPMRegistry: npm publish
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~25 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Review rate limit: 6/8 reviews remaining, refill in 9 minutes and 9 seconds.Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/rc-release.yml:
- Around line 78-79: The code directly indexes manifest[path] which raises a raw
KeyError when the path is missing; update the logic around manifest =
json.loads(os.environ['MANIFEST_JSON']) and the subsequent access to check for
the key first (e.g., if path not in manifest) and handle the missing entry by
printing a clear error message (including the path) to stderr and exiting with a
non-zero code, or use manifest.get(path) and validate the result before printing
so the workflow fails with an explicit, helpful error instead of a traceback.
🪄 Autofix (Beta)
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
Run ID: 6684f57c-235c-45e0-a758-57baa4640719
📒 Files selected for processing (1)
.github/workflows/rc-release.yml
Drop NPM_TOKEN in favour of OIDC-based Trusted Publishing now that the package is configured for it on npm. The reusable workflow grants the publish job id-token: write, upgrades npm to a version that supports Trusted Publishing (>= 11.5.1) since setup-node ships an older npm, and stops setting NODE_AUTH_TOKEN. Both callers (rc-release, release-please) drop the NPM_TOKEN secret and forward id-token: write.
Contributor
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/publish-wren-core-wasm.yml:
- Around line 63-65: Change the workflow step labeled "Upgrade npm (Trusted
Publishing requires >= 11.5.1)" to pin npm to the known-good minimum by
replacing the unstable `npm@latest` with the explicit version `npm@11.5.1`;
update the run command in that step to install `npm@11.5.1` so releases are
deterministic and meet the Trusted Publishing requirement.
🪄 Autofix (Beta)
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
Run ID: 3d43736d-c51d-4a49-9af7-09ac7d5c4e0d
📒 Files selected for processing (3)
.github/workflows/publish-wren-core-wasm.yml.github/workflows/rc-release.yml.github/workflows/release-please.yml
🚧 Files skipped from review as they are similar to previous changes (1)
- .github/workflows/rc-release.yml
…t error - npm Trusted Publishing requires Node.js >= 22.14.0 (per npm docs). Node 20 doesn't meet that, so bump the wasm publish workflow to Node 24. Keep the explicit 'npm install -g npm@latest' as a belt-and-suspenders guarantee for the npm >= 11.5.1 requirement. - Replace the raw KeyError on a missing manifest path with an explicit sys.exit message so workflow failures are easier to triage.
2 tasks
PaulChen79
approved these changes
May 4, 2026
1 task
This was referenced May 5, 2026
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
2 participants
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.
Summary
Triggering RC Release for
wrenproducedwren-v0.3.0-rc.1instead of the expectedwren-v0.4.0-rc.1. Same class of bug for the other components..release-please-manifest.jsononmainstores the last released version, not the next one. The next version lives on the per-component release-please branch (release-please--branches--main--components--<component>), where release-please bumps the manifest entry as part of the proposed release PR.This change reads the manifest from that branch when computing
BASE_VERSION. If the branch doesn't exist (no pending release for the component), the workflow now fails with a clear error message instead of silently producing an RC for the already-released version.Verification
Locally resolved next-release versions from each release-please branch:
main(released)wren0.3.00.4.0✅wren-core-py0.4.00.5.0✅wren-core-wasm0.1.00.2.0✅After this fix, dispatching
RC Releasewithcomponent=wrenwill producewren-v0.4.0-rc.1.Cleanup note
Three RC tags were created with the buggy versions and should probably be deleted manually:
wren-v0.3.0-rc.1wren-core-py-v0.4.0-rc.1wren-core-wasm-v0.1.0-rc.2Test plan
component=wrenand confirm it tagswren-v0.4.0-rc.1.🤖 Generated with Claude Code
Summary by CodeRabbit