fix: only update tag for a released type event #315
Conversation
shenxianpeng
requested review from
2bndy5 and
Copilot
and removed request for
a team
There was a problem hiding this comment.
Pull Request Overview
This PR fixes the GitHub Actions workflow trigger to prevent updating the v2 tag when a pre-release is published. The change ensures that only actual releases (not pre-releases) trigger the tag update workflow.
- Changes the release event type from
publishedtoreleasedin the workflow trigger
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
WalkthroughUpdated the GitHub Actions release workflow to trigger on the release event type "released" instead of "published." No other workflow configuration or steps were changed. Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~2 minutes ✨ Finishing Touches🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (5)
.github/workflows/release.yml (5)
5-5: branches filter is not supported for release eventsThe release event doesn’t support branch filters; this key is ignored. Consider removing it for correctness and to avoid confusion.
Apply this diff:
- branches: [main]
23-26: Make checkout ref robust across triggers (release vs. workflow_dispatch)ref: ${{ inputs.ref }} will be empty for release-triggered runs. While actions/checkout may fall back, it’s safer and clearer to explicitly select the release tag when present, or the workflow input when manually dispatched.
Apply this diff:
with: fetch-depth: 0 - ref: ${{ inputs.ref }} + # Prefer the manual input when provided, otherwise use the release tag (or default ref) + ref: ${{ inputs.ref || github.event.release.tag_name || github.ref }}
31-39: Harden conditions for manual vs. release runsRelying on github.event.inputs.tag being '' for non-dispatch events is brittle. Make the event explicit to avoid surprises and improve readability.
Apply this diff:
- if: github.event.inputs.tag != '' + # Run only for manual dispatch when a tag is provided + if: github.event_name == 'workflow_dispatch' && inputs.tag != '' @@ - if: github.event.inputs.tag == '' + # Run for release events or for manual dispatch when no tag is provided + if: github.event_name == 'release' || (github.event_name == 'workflow_dispatch' && inputs.tag == '')
19-21: Ensure token permissions allow pushing tagsIf the repository’s default workflow permissions are read-only, pushing/deleting tags will fail. Grant contents: write at the job level.
Apply this diff:
re-tag: + permissions: + contents: write runs-on: ubuntu-latest
30-43: Optional: simplify re-tagging with force-push instead of delete+recreateDeleting then pushing introduces a brief gap where the tag doesn’t exist. A force update is simpler and atomic.
Here’s an example for the v2 step (apply similarly to the parameterized step):
- git tag --delete v2 || true - git push --delete origin v2 || true - git tag -a v2 -m 'Retag v2' - git push origin v2 + git tag -fa v2 -m 'Retag v2' + git push --force-with-lease origin refs/tags/v2
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
💡 Knowledge Base configuration:
- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (1)
.github/workflows/release.yml(1 hunks)
🔇 Additional comments (2)
.github/workflows/release.yml (2)
6-6: Correct event type: switching to released avoids pre-release runsUsing types: [released] ensures the workflow won’t run for pre-releases. This aligns with the PR objective. Looks good.
22-22: Confirmed actions/checkout@v5 is correct
- Verified that actions/checkout@v5 exists and is the current stable major version as of August 2025.
- No changes needed.
|
We could also use I don't actually use release-drafter for any other projects. Instead I use a CI |
|
That’s right—release-drafter is limited to updating files like README, CHANGELOG, etc. It’s still a good and simple way to automate releases, and I’d prefer not to change it unless it truly stops working well for us. |
|
Any reason to not publish v2.16.1? I See the draft has to be altered about the version number. Also the pre-release flag can be removed from v2.16.0 release if we are going to publish v2.16.1. |
|
I forgot we have a draft release. The easiest way is to delete the draft, so I did it. And the new release is v2.16.0 |
I think there are some changes missing from the newly generated release notes. |
|
In the future, it is probably better to just delete the tag if we want to "yank" a release. |
Yes. It is. I missed switching uv change note |
Good point |
|
I am continuing to make mistakes 😵💫 I'll need a little time later to get everything organized. |
Right now, if we published a pre-release, the tag
v2will also be updated to point to the pre-release. which is not what we wanted.We should change the type to released
Summary by CodeRabbit