fix(ci): add prerelease versioning to release-please config#305
Conversation
…e release trigger - Add "versioning": "prerelease" to release-please-config.json so release-please generates RC versions instead of stable versions - Add "published" to release.yml trigger types so stable releases also build artifacts
✅ Deploy Preview for devsydev canceled.
|
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThis PR updates release automation configuration to support prerelease versioning. The GitHub Actions workflow now triggers on both ChangesPrerelease support
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. 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 |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
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 @.github/workflows/release.yml:
- Line 4: The workflow currently lists release event types as "types:
[prereleased, published]" causing duplicate runs; change the event trigger to
only "types: [published]" and then control job behavior by checking the
release's prerelease flag (use conditions like "if:
github.event.release.prerelease == true" or "== false") inside the affected
jobs; update the release trigger definition (the "types" key) and add
appropriate "if" conditions to jobs that must differ between prerelease and
stable flows so only one run fires and job logic branches on
github.event.release.prerelease.
🪄 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: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: bb921ef3-9e96-45e5-88a5-50fc2499530d
📒 Files selected for processing (2)
.github/workflows/release.ymlrelease-please-config.json
| on: | ||
| release: | ||
| types: [prereleased] | ||
| types: [prereleased, published] |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
For GitHub Actions release` events, what action values are emitted for:
- publishing a prerelease,
- publishing a stable release from draft,
- promoting an existing prerelease to stable?
Doestypes: [prereleased, published]risk duplicate workflow runs for prerelease publication, and isreleasedrequired for prerelease->stable promotion?`
💡 Result:
For GitHub Actions release events, the action values emitted are as follows: 1) Publishing a prerelease: Emits prereleased if created directly as a prerelease, or published if published from a draft [1][2]. 2) Publishing a stable release from draft: Emits published [1][3]. 3) Promoting an existing prerelease to stable: Emits published when the release is edited and the "This is a pre-release" checkbox is unchecked [1]. Regarding your specific questions: - Does types: [prereleased, published] risk duplicate workflow runs for prerelease publication? Yes, it can. If a prerelease is published directly (not from a draft), it may trigger both prereleased and published depending on the specific GitHub API behavior and how the release is created [1][2]. GitHub documentation explicitly recommends subscribing only to published if you want a workflow to run for both stable and prereleases, as published triggers for both [1]. - Is released required for prerelease->stable promotion? No, released is not required. The published activity type is the standard trigger for when a release is made public, including when a prerelease is promoted to a stable release [1]. The released activity type is generally not used for these standard publication workflows [1]. In summary, to avoid duplicate runs and ensure consistent behavior, it is best practice to use types: [published] and handle the distinction between stable and prerelease versions within your workflow jobs using conditional logic, such as checking the github.event.release.prerelease boolean property [1][2].
Citations:
- 1: https://docs.github.com/actions/using-workflows/events-that-trigger-workflows
- 2: New v2.5.0 feature prevents
prereleasedevent trigger for a separate workflow softprops/action-gh-release#708 - 3: https://www.codegenes.net/blog/github-action-different-between-release-created-and-published/
Use types: [published] and handle stable vs prerelease in the workflow.
The current types: [prereleased, published] can trigger duplicate runs when a prerelease is published directly. Simplify to types: [published] (which triggers for both stable and prerelease releases) and use if: github.event.release.prerelease == false (or == true) within jobs to distinguish behavior between stable and prerelease. The released action type is not needed for prerelease-to-stable promotions—published handles that case.
🤖 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/release.yml at line 4, The workflow currently lists
release event types as "types: [prereleased, published]" causing duplicate runs;
change the event trigger to only "types: [published]" and then control job
behavior by checking the release's prerelease flag (use conditions like "if:
github.event.release.prerelease == true" or "== false") inside the affected
jobs; update the release trigger definition (the "types" key) and add
appropriate "if" conditions to jobs that must differ between prerelease and
stable flows so only one run fires and job logic branches on
github.event.release.prerelease.
CodeRabbit: prereleased+published can double-fire on direct prerelease publish. published alone triggers for both stable and prerelease; the prerelease job already gates on github.event.release.prerelease.
1 participant
Summary
\"versioning\": \"prerelease\"torelease-please-config.json— without this key, release-please uses default versioning and produces stable versions instead of RC versions despite\"prerelease\": truebeing setpublishedtorelease.ymltrigger types ([prereleased, published]) so stable releases promoted from RC also trigger artifact buildsSummary by CodeRabbit