feat(release): announce releases from the release umbrella workflow - #629
Merged
Conversation
Add an announce_release job to release.yml that calls release-notification.yml after a successful release, routing the announcement per repository: channel from announcement_slack_channel or the RELEASE_SLACK_CHANNEL variable, webhook from the RELEASE_WEBHOOK_URL secret (RELEASE_WEBHOOK_NOTIFICATION_URL kept as fallback). The job is skipped when no channel is configured and the notification step is skipped when the webhook secret is absent. release-notification.yml gains an optional release_tag input so the umbrella announces the tag actually published by the run instead of the newest release in the repository, which was wrong for monorepo matrix legs. go-release.yml and js-release.yml expose the three new inputs and pass them through to release.yml. Discord is not wired into the umbrella job: SethCohen/github-releases-to-discord reads the release event payload, absent on the push event that drives release.yml. Discord announcements stay on a dedicated on: release caller.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yml Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (1)
Summary by CodeRabbit
WalkthroughRelease workflows now expose configurable Slack announcement inputs, dispatch notifications after release finalization, and support explicit release-tag resolution with documented fallbacks and webhook configuration. ChangesRelease announcements
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
lerian-studio
added
size/S
Contributor
🔍 PR Validation Summary✅ PR Mergeable — no blocking failures
|
Contributor
🔍 Lint Analysis
|
Contributor
🛡️ CodeQL Analysis ResultsLanguages analyzed: ✅ No security issues found. 🔍 View full scan logs | 🛡️ Security tab |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Warning
CodeRabbit couldn't request changes on this pull request because it doesn't have sufficient GitHub permissions.
Please grant CodeRabbit Pull requests: Read and write permission and re-run the review.
Actionable comments posted: 2
🤖 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-notification.yml:
- Around line 138-147: Update the release-tag resolution step and the later
dry-run summary to avoid embedding caller-controlled values in shell source:
expose the resolved tag through the step’s env configuration and reference it as
$RESOLVED_TAG, applying the same env-based handling to every interpolated input
used in that summary while preserving the existing tag fallback behavior.
In @.github/workflows/release.yml:
- Around line 638-642: Update the announcement job gate in the release workflow
so dry_run can proceed without requiring
needs.publish_release_status.outputs.release_published to equal 'true'. Preserve
the existing publication requirement for normal runs, and ensure the dry-run
path passes the intended preview tag to release-notification.yml so the
documented payload preview is produced.
🪄 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: Path: .coderabbit.yml
Review profile: ASSERTIVE
Plan: Pro
Run ID: f2f2dd8a-1115-4696-bd60-d04689182158
📒 Files selected for processing (8)
.github/workflows/go-release.yml.github/workflows/js-release.yml.github/workflows/release-notification.yml.github/workflows/release.ymldocs/go-release-workflow.mddocs/js-release.mddocs/release-notification.mddocs/release-workflow.md
The Discord and Slack release composites were pinned to @v1.18.0, which the pinned-actions lint flags: internal composites must use the floating major tag (@vn) while internal reusable workflows use an exact version. Aligns both refs with the rest of the repository.
There was a problem hiding this comment.
♻️ Duplicate comments (1)
.github/workflows/release-notification.yml (1)
138-147:⚠️ Potential issue | 🔴 CriticalStill avoid interpolating the resolved tag into shell source.
The caller-controlled tag is safely received through
envhere, but it is later embedded directly in the dry-run script at Line 169. Export it through the step’senv:and reference$RESOLVED_TAG; apply the same pattern to every caller-controlled value used by that summary.As per coding guidelines, never interpolate untrusted user input directly into
run:commands; pass it through an environment variable.🤖 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-notification.yml around lines 138 - 147, Update the release-notification step’s dry-run summary to avoid interpolating the resolved release tag or any other caller-controlled summary values into the run script. Export each value through the step’s env configuration, including the resolved tag as RESOLVED_TAG, and reference the corresponding shell variables throughout the summary while preserving the existing tag resolution behavior.Source: Coding guidelines
🤖 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.
Duplicate comments:
In @.github/workflows/release-notification.yml:
- Around line 138-147: Update the release-notification step’s dry-run summary to
avoid interpolating the resolved release tag or any other caller-controlled
summary values into the run script. Export each value through the step’s env
configuration, including the resolved tag as RESOLVED_TAG, and reference the
corresponding shell variables throughout the summary while preserving the
existing tag resolution behavior.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yml
Review profile: ASSERTIVE
Plan: Pro
Run ID: 5dd4f92a-d9d4-47b6-a9fc-250926231d19
📒 Files selected for processing (1)
.github/workflows/release-notification.yml
CodeQL flagged the dry-run summary step for interpolating product_name, slack_channel and the resolved release tag straight into the run block. Every value now reaches bash as an environment variable, and the discord/slack enable flags are computed in shell instead of via expression interpolation.
lerian-studio
added
size/M
5 tasks
14 tasks
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.
GitHub Actions Shared Workflows
Description
Release announcements were only reachable through a standalone caller workflow wired on
on: release, so each repository had to duplicate that wiring and the shared release pipeline had no knowledge of where its announcement should land. This PR moves the announcement into the release umbrella and makes the routing per-repository.release.yml— newannounce_releasejob that callsrelease-notification.ymlafter a successful release. Routing is resolved entirely from the calling repository:announcement_slack_channelinput, falling back to theRELEASE_SLACK_CHANNELrepository variableRELEASE_WEBHOOK_URLrepository secret, falling back toRELEASE_WEBHOOK_NOTIFICATION_URL(already in use by some repos)publish_release_status.outputs.release_git_tagThe job is skipped when no channel is configured, and the notification step inside
release-notification.ymlis skipped (non-fatal) when the webhook secret is absent. Three new inputs:enable_release_announcement(defaulttrue),announcement_product_name,announcement_slack_channel.release-notification.yml— new optionalrelease_taginput. The tag resolution chain becomesrelease_tag→github.event.release.tag_name→gh release list --limit 1. Without it the umbrella would announce the newest release in the repository, which is the wrong tag on monorepo runs where a matrix leg other than the last one published. The input is deliberately not exposed onworkflow_dispatch(free-text string reaching shell/composite interpolation).go-release.yml/js-release.yml— both already delegate torelease.yml, so they only expose the three new inputs and pass them through.Discord is intentionally not wired into the umbrella job.
SethCohen/github-releases-to-discordreadsgithub.context.payload.release(index.js:117), which does not exist on thepushevent that drivesrelease.yml.DISCORD_WEBHOOK_URLis not forwarded, so Discord announcements keep working through a dedicatedon: releasecaller ofrelease-notification.yml.Docs updated:
docs/release-workflow.md(new Release Announcement section with consuming-repo setup, behavior matrix, Discord limitation and duplicate-announcement warning),docs/release-notification.md,docs/go-release-workflow.md,docs/js-release.md.Type of Change
feat: New workflow or new input/output/step in an existing workflowfix: Bug fix in a workflow (incorrect behavior, broken step, wrong condition)perf: Performance improvement (e.g. caching, parallelism, reduced steps)refactor: Internal restructuring with no behavior changedocs: Documentation only (README, docs/, inline comments)ci: Changes to self-CI (workflows under.github/workflows/that run on this repo)chore: Dependency bumps, config updates, maintenancetest: Adding or updating testsBREAKING CHANGE: Callers must update their configuration after this PRBreaking Changes
None. No input or output was renamed, removed or type-changed, and every new input defaults to the previous behavior.
Two behavior notes for callers:
enable_release_announcementdefaults totrue, so a repository that already has both a channel (announcement_slack_channelorRELEASE_SLACK_CHANNEL) and a webhook secret starts announcing without opting in. With no channel configured nothing is sent.on: releaseworkflow will receive two Slack messages once this job is active. Remove the standalone Slack announcement there, or setenable_release_announcement: false.Nesting depth is worth noting:
caller → go-release.yml/js-release.yml→release.yml→release-notification.ymlis 4 levels, the maximum GitHub allows for reusable workflows.Testing
@this-branchor the beta tagValidation performed:
yaml.safe_loadover the four changed workflows; the newrelease_tagvalue is passed throughenvinstead of being interpolated directly into the shell; the existingnotifyjob (CI status viaslack-notify.yml) is untouched andannounce_releaseis not added to itsneeds, so a failed announcement cannot mark the release as failed.typescript-release.ymlhas its own publish path and does not go throughrelease.yml, so it is unaffected.Related Issues
Closes #611