ci(release): make the Discord announcement dispatchable on its own - #289
Open
EtienneLescot wants to merge 1 commit into
Open
ci(release): make the Discord announcement dispatchable on its own#289EtienneLescot wants to merge 1 commit into
EtienneLescot wants to merge 1 commit into
Conversation
Announcing a release only ever existed as the final step of prerelease.yml and promote.yml. Both promotions so far failed before reaching it — v1.8.0 on a merge conflict, v1.9.0 on a non-rebasable sync branch — and each time the announcement was skipped along with everything downstream of the failure. Recovering it meant re-running a promotion over an already-tagged release, which re-attempts tagging and the main merge; nobody was going to do that for a Discord post, so v1.9.0 simply shipped unannounced. This wraps the existing discord-release-announce.mjs in a workflow_dispatch and changes nothing else. The message is derived entirely from the tag and the matching milestone, so a late announcement is identical to the one that would have gone out on time. The destination is selected by blanking one of the two channel variables rather than by KIND, because that is what the script actually branches on: it prefers DISCORD_RC_TESTING_CHANNEL_ID whenever it is non-empty.
📝 WalkthroughWalkthroughThe pull request adds a manually dispatched GitHub Actions workflow. The workflow accepts a release tag, release kind, and optional message, then runs the Discord release announcement script with the required configuration. ChangesRelease announcement workflow
Estimated code review effort: 2 (Simple) | ~10 minutes Possibly related PRs
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ 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 |
![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/announce-release.yml:
- Line 60: Update the announcement script invocation in the workflow and the
corresponding logic in discord-release-announce.mjs to support strict mode for
manual announcements. Enable strict mode from announce-release.yml, and ensure
missing Discord configuration, channel lookup failures, and post failures exit
with a non-zero status while preserving current behavior when strict mode is not
enabled.
🪄 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: defaults
Review profile: CHILL
Plan: Pro Plus
Run ID: 2b72a33b-5ca6-48d5-bf53-2bc95d26de24
📒 Files selected for processing (1)
.github/workflows/announce-release.yml
| STABLE_TAG: ${{ inputs.tag }} | ||
| EXTRA: ${{ inputs.release_notes_extra }} | ||
| KIND: ${{ inputs.kind }} | ||
| run: node .github/scripts/discord-release-announce.mjs |
There was a problem hiding this comment.
🩺 Stability & Availability | 🟠 Major | ⚡ Quick win
Fail the job when the announcement is not sent.
.github/scripts/discord-release-announce.mjs exits with status 0 when Discord configuration is missing, the channel lookup fails, or the post fails. This workflow then reports success although it sent no announcement. That recreates the silent failure that this workflow is intended to recover from.
Add a strict mode for manual announcements. In strict mode, make missing configuration and Discord API failures exit non-zero.
🤖 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/announce-release.yml at line 60, Update the announcement
script invocation in the workflow and the corresponding logic in
discord-release-announce.mjs to support strict mode for manual announcements.
Enable strict mode from announce-release.yml, and ensure missing Discord
configuration, channel lookup failures, and post failures exit with a non-zero
status while preserving current behavior when strict mode is not enabled.
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
1 participant
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.
Why
Announcing a release only ever existed as the last step of
prerelease.ymlandpromote.yml. Both promotions so far failed before reaching it:Merge release branch into mainfailed on merge conflictsThis branch can't be rebasedEach time the announcement was skipped along with everything downstream of the failure. Recovering it meant re-running a whole promotion over an already-tagged release — which re-attempts tagging and the main merge — so nobody was going to do that for a Discord post. v1.9.0 shipped unannounced.
What this does
Wraps the existing
.github/scripts/discord-release-announce.mjsin aworkflow_dispatch. No change to the script, and no change to either release workflow.The message is derived entirely from the tag and the matching milestone, so a late announcement is byte-identical to the one that would have gone out on time. That is what makes this safe to run after the fact rather than a reconstruction.
One non-obvious detail
The destination is chosen by blanking one of the two channel variables, not by the
KINDinput:because that is what the script actually branches on — it prefers
DISCORD_RC_TESTING_CHANNEL_IDwhenever it is non-empty, andKINDonly selects the embed's wording and colour. Setting both would post a "released" embed into the RC testing channel.After merging
That sends the announcement v1.9.0 never got. It is safe to re-run — the only consequence of a double dispatch is a duplicate post, and
allowed_mentionsis empty so nothing is pinged either way.Not addressed here
The reason promotions keep failing at the main-sync step is separate and still open:
mainand the release branch accumulate the same fixes under different SHAs, so GitHub's rebase-merge replays commits already present. Worth its own change — this PR only stops one recurring casualty of it.