Skip release note creation for RC releases#424
Conversation
Skip the create-release job when the target-release version contains the -rc<Number> postfix (e.g., 0.0.1-rc1), as RC releases do not require a GitHub release note.
📝 WalkthroughWalkthroughThe GitHub Actions release workflow now includes a conditional check to prevent the Create Release job from executing when the target release version contains a Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 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. Comment |
a5anka
changed the title
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
🧹 Nitpick comments (2)
.github/workflows/release.yml (2)
172-185: Heads-up: floating major-version tag is still updated for RC releases
prepare-releaseunconditionally moves the major version tag (e.g.,amp/v0) to the RC commit (lines 172–185). After this PR, RC builds will produce images, charts, and a git tag — and silently shift theamp/v0floating tag to an RC commit — without creating a corresponding GitHub release. Consumers pinned to the major tag will transparently receive RC artifacts.This is pre-existing behaviour, but it becomes more likely to be triggered now that the workflow explicitly accommodates
-rcversions. Consider adding the same!contains(inputs.target-release, '-rc')guard to the major-tag block, or document that this is intentional.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release.yml around lines 172 - 185, The workflow unconditionally moves the floating major tag (MAJOR_TAG derived from MAJOR_VERSION) even for release candidates, causing amp/vX to point at RC commits; update the prepare-release job so the major-tag block (the logic that computes MAJOR_VERSION/MAJOR_TAG and deletes/pushes the tag) only runs when inputs.target-release does NOT contain "-rc" (use GitHub Actions expression like !contains(inputs.target-release, '-rc')) to skip MAJOR_TAG creation/update for RCs, or alternatively document that prepare-release intentionally updates MAJOR_TAG for RCs if you prefer that behavior.
362-362: LGTM — minor note on the match breadth
contains(inputs.target-release, '-rc')is a plain substring check, so it will also gate versions like0.0.1-rcandidateor0.0.1-rc(no trailing number). Given that the only convention described in the PR is-rc<Number>, this is intentionally conservative and unlikely to cause false positives in practice.If you ever want to restrict the gate to the exact
-rc<Number>pattern documented in the PR description, astartsWith-safe approach would be:💡 Optional: tighten the condition to the documented pattern
- if: ${{ !contains(inputs.target-release, '-rc') }} + if: ${{ !contains(inputs.target-release, '-rc') || !contains(inputs.target-release, '-rc') }}Actually, GitHub Actions expressions don't support regex natively in
if, but you can express it clearly via the existingvalidatestep — set an output likeis-rc=truethere and referencesteps.validate.outputs.is-rc != 'true'here. This is purely optional given the current conventions.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/release.yml at line 362, The current gating condition uses contains(inputs.target-release, '-rc') which is a substring check; instead, set a boolean output in your existing validate step (e.g., steps.validate.outputs.is-rc = 'true' when the tag matches the documented -rc<Number> pattern) and replace the if with a precise check: use if: steps.validate.outputs.is-rc != 'true' to only block true release-candidate patterns; update the validate logic to compute is-rc using the exact pattern logic you want and reference steps.validate.outputs.is-rc in the job that currently uses contains(inputs.target-release, '-rc').
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In @.github/workflows/release.yml:
- Around line 172-185: The workflow unconditionally moves the floating major tag
(MAJOR_TAG derived from MAJOR_VERSION) even for release candidates, causing
amp/vX to point at RC commits; update the prepare-release job so the major-tag
block (the logic that computes MAJOR_VERSION/MAJOR_TAG and deletes/pushes the
tag) only runs when inputs.target-release does NOT contain "-rc" (use GitHub
Actions expression like !contains(inputs.target-release, '-rc')) to skip
MAJOR_TAG creation/update for RCs, or alternatively document that
prepare-release intentionally updates MAJOR_TAG for RCs if you prefer that
behavior.
- Line 362: The current gating condition uses contains(inputs.target-release,
'-rc') which is a substring check; instead, set a boolean output in your
existing validate step (e.g., steps.validate.outputs.is-rc = 'true' when the tag
matches the documented -rc<Number> pattern) and replace the if with a precise
check: use if: steps.validate.outputs.is-rc != 'true' to only block true
release-candidate patterns; update the validate logic to compute is-rc using the
exact pattern logic you want and reference steps.validate.outputs.is-rc in the
job that currently uses contains(inputs.target-release, '-rc').
2 participants
Summary
ifcondition to thecreate-releasejob in the release pipeline to skip GitHub release note creation when thetarget-releaseversion contains the-rc<Number>postfix (e.g.,0.0.1-rc1,1.2.3-rc10)Summary by CodeRabbit