Add Slack PR notification workflows - #11
Conversation
|
Warning Review limit reached
More reviews will be available in 5 minutes and 33 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based credits. 🚦 How do rate limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan refill rate. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, the refill rate gradually slows as usage increases. The highest same-day bursts are limited more strictly. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughThree GitHub Actions workflow files are added to send Slack notifications at distinct PR lifecycle points: when a PR is opened or ready for review, when a review is requested or submitted, and when a PR is closed or merged. Each workflow includes bot/dependency guards, GitHub-to-Slack user resolution, and curl-based webhook delivery with HTTP 200 validation. ChangesPR Lifecycle Slack Notifications
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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: 10
🤖 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/pr-closed-notify-slack.yml:
- Line 11: The job identified as "notify" in the workflow file is missing an
explicit name field, which reduces visibility in GitHub Actions logs and UI. Add
a descriptive `name` field to the "notify" job that clearly describes what the
job does, such as notifying Slack about closed pull requests. This will improve
workflow transparency and make it easier to identify the job in GitHub Actions
outputs.
- Around line 7-8: The permissions block in the GitHub workflow file lacks
documentation explaining why the pull-requests: read permission is required. Add
an explanatory comment above or on the same line as the pull-requests: read
permission that clarifies why this permission is necessary for the workflow to
function properly (e.g., to access pull request metadata or details needed for
the Slack notification).
- Around line 13-15: The conditional check in the workflow is missing two
filters for consistency with pr-opened-notify-slack.yml. Add two additional
conditions to the existing if statement: first, exclude PRs labeled with
'ignore-for-release' by using a contains check on the labels array similar to
the existing 'dependencies' check, and second, exclude draft PRs by checking
that the pull request is not in draft status. Both conditions should be combined
with the existing conditions using AND operators to ensure the workflow only
triggers for non-draft, non-bot-authored PRs that lack both the 'dependencies'
and 'ignore-for-release' labels.
In @.github/workflows/pr-in-review-notify-slack.yml:
- Around line 9-10: The permissions block in the workflow file contains a
pull-requests: read permission that lacks documentation explaining its purpose.
Add a comment above the pull-requests: read line in the permissions block to
explain why this permission is necessary for the workflow to function properly,
such as indicating it is needed to read pull request information for the
notification logic.
- Line 13: The `notify` job in the workflow file lacks a descriptive `name`
field, which reduces visibility in GitHub Actions UI and logs. Add a `name`
field to the `notify` job with a clear, descriptive value that explains what the
job does (such as notifying Slack). This should be added as a direct property of
the notify job definition to improve workflow readability and debugging.
- Around line 15-19: The if condition evaluates fields that may not exist
depending on which event triggered the workflow. The
github.event.requested_reviewer.type field only exists on pull_request
review_requested events, while github.event.review.user.type only exists on
pull_request_review events. This causes undefined field access and incorrect
boolean evaluation. Fix this by refactoring the condition to either use OR logic
between the two bot type checks (allowing at least one to pass since one will
always be null) or by first checking the event type to determine which bot field
is safe to access, ensuring the job only runs when appropriate regardless of
which event type triggered the workflow.
- Around line 15-19: The workflow is missing a filter check that exists in
pr-opened-notify-slack.yml for consistency. In the if condition block that
currently checks for draft status, dependencies label, and bot types, add a new
check using contains() to filter out pull requests labeled with
'ignore-for-release'. This check should be added as an additional condition with
the logical AND operator (!contains(github.event.pull_request.labels.*.name,
'ignore-for-release')) to ensure that PRs marked for release exemption do not
trigger Slack notifications when reviewers are requested or reviews are
submitted.
In @.github/workflows/pr-opened-notify-slack.yml:
- Around line 8-9: The permissions block containing pull-requests: read lacks
documentation explaining why this permission is necessary. Add an explanatory
comment above or inline with the pull-requests: read permission statement in the
permissions block to clarify what this permission is used for and why it is
required by the workflow. This will help future maintainers understand the
purpose and necessity of granting this permission.
- Line 12: The `notify` job in the workflow file is missing an explicit `name`
field, which reduces visibility in the GitHub Actions UI. Add a `name` field to
the `notify` job with a descriptive value that clearly indicates the job's
purpose, such as notifying Slack when a pull request is opened. This will
improve readability in workflow run logs and make it easier to identify the
job's purpose at a glance.
- Around line 38-51: The organization variable `vars.SLACK_TO_GITHUB` is named
misleadingly—the data structure and jq query indicate it contains mappings of
GitHub users to Slack IDs (a GitHub→Slack mapping), not the reverse. Rename the
organization variable from `SLACK_TO_GITHUB` to `GITHUB_TO_SLACK` in your
organization settings to accurately reflect the data direction. Then update the
environment variable assignment on line 42 where `vars.SLACK_TO_GITHUB` is
referenced to use `vars.GITHUB_TO_SLACK` instead, and rename the environment
variable `GITHUB_TO_SLACK` to match the org variable name for consistency.
🪄 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: ASSERTIVE
Plan: Pro
Run ID: 2931b7d1-87c0-4d34-8a82-8c9fcf9fda1b
📒 Files selected for processing (3)
.github/workflows/pr-closed-notify-slack.yml.github/workflows/pr-in-review-notify-slack.yml.github/workflows/pr-opened-notify-slack.yml
| permissions: | ||
| pull-requests: read |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial | 💤 Low value
Add explanatory comment to permissions block.
The pull-requests: read permission lacks documentation on its necessity.
📝 Proposed comment addition
permissions:
+ # Used to read PR details (merged status, labels, author type) for filtering and notifications
pull-requests: read📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| permissions: | |
| pull-requests: read | |
| permissions: | |
| # Used to read PR details (merged status, labels, author type) for filtering and notifications | |
| pull-requests: read |
🧰 Tools
🪛 zizmor (1.25.2)
[warning] 8-8: permissions without explanatory comments (undocumented-permissions): needs an explanatory comment
(undocumented-permissions)
🤖 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/pr-closed-notify-slack.yml around lines 7 - 8, The
permissions block in the GitHub workflow file lacks documentation explaining why
the pull-requests: read permission is required. Add an explanatory comment above
or on the same line as the pull-requests: read permission that clarifies why
this permission is necessary for the workflow to function properly (e.g., to
access pull request metadata or details needed for the Slack notification).
Source: Linters/SAST tools
| pull-requests: read | ||
|
|
||
| jobs: | ||
| notify: |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial | 💤 Low value
Add an explicit name to the job.
The job lacks a descriptive name field for better workflow visibility in GitHub Actions UI and logs.
✨ Proposed addition
jobs:
notify:
+ name: Notify Slack on PR Closed/Merged
runs-on: ubuntu-latest📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| notify: | |
| jobs: | |
| notify: | |
| name: Notify Slack on PR Closed/Merged | |
| runs-on: ubuntu-latest |
🧰 Tools
🪛 zizmor (1.25.2)
[info] 11-11: workflow or action definition without a name (anonymous-definition): this job
(anonymous-definition)
🤖 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/pr-closed-notify-slack.yml at line 11, The job identified
as "notify" in the workflow file is missing an explicit name field, which
reduces visibility in GitHub Actions logs and UI. Add a descriptive `name` field
to the "notify" job that clearly describes what the job does, such as notifying
Slack about closed pull requests. This will improve workflow transparency and
make it easier to identify the job in GitHub Actions outputs.
Source: Linters/SAST tools
| if: | | ||
| !contains(github.event.pull_request.labels.*.name, 'dependencies') && | ||
| github.event.pull_request.user.type != 'Bot' |
There was a problem hiding this comment.
Add 'ignore-for-release' filter for consistency and draft PR filtering.
This workflow lacks two filters present in pr-opened-notify-slack.yml:
- 'ignore-for-release' label check: If a PR is labeled 'ignore-for-release' and closed/merged, this workflow will still trigger. For consistency and to respect the PR's exemption from release tracking, add this filter.
- Draft PR check (line 16 in file 1): While draft PRs are unlikely to transition to closed naturally, adding this check maintains defensive filtering consistency across all three workflows.
✅ Proposed addition
if: |
+ !github.event.pull_request.draft &&
!contains(github.event.pull_request.labels.*.name, 'dependencies') &&
+ !contains(github.event.pull_request.labels.*.name, 'ignore-for-release') &&
github.event.pull_request.user.type != 'Bot'📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| if: | | |
| !contains(github.event.pull_request.labels.*.name, 'dependencies') && | |
| github.event.pull_request.user.type != 'Bot' | |
| if: | | |
| !github.event.pull_request.draft && | |
| !contains(github.event.pull_request.labels.*.name, 'dependencies') && | |
| !contains(github.event.pull_request.labels.*.name, 'ignore-for-release') && | |
| github.event.pull_request.user.type != 'Bot' |
🤖 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/pr-closed-notify-slack.yml around lines 13 - 15, The
conditional check in the workflow is missing two filters for consistency with
pr-opened-notify-slack.yml. Add two additional conditions to the existing if
statement: first, exclude PRs labeled with 'ignore-for-release' by using a
contains check on the labels array similar to the existing 'dependencies' check,
and second, exclude draft PRs by checking that the pull request is not in draft
status. Both conditions should be combined with the existing conditions using
AND operators to ensure the workflow only triggers for non-draft,
non-bot-authored PRs that lack both the 'dependencies' and 'ignore-for-release'
labels.
| permissions: | ||
| pull-requests: read |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial | 💤 Low value
Add explanatory comment to permissions block.
The pull-requests: read permission lacks documentation on its necessity.
📝 Proposed comment addition
permissions:
+ # Used to read PR details for filtering and reviewer information
pull-requests: read📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| permissions: | |
| pull-requests: read | |
| permissions: | |
| # Used to read PR details for filtering and reviewer information | |
| pull-requests: read |
🧰 Tools
🪛 zizmor (1.25.2)
[warning] 10-10: permissions without explanatory comments (undocumented-permissions): needs an explanatory comment
(undocumented-permissions)
🤖 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/pr-in-review-notify-slack.yml around lines 9 - 10, The
permissions block in the workflow file contains a pull-requests: read permission
that lacks documentation explaining its purpose. Add a comment above the
pull-requests: read line in the permissions block to explain why this permission
is necessary for the workflow to function properly, such as indicating it is
needed to read pull request information for the notification logic.
Source: Linters/SAST tools
| pull-requests: read | ||
|
|
||
| jobs: | ||
| notify: |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial | 💤 Low value
Add an explicit name to the job.
The job lacks a descriptive name field for better workflow visibility in GitHub Actions UI and logs.
✨ Proposed addition
jobs:
notify:
+ name: Notify Slack on PR Review
runs-on: ubuntu-latest📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| notify: | |
| jobs: | |
| notify: | |
| name: Notify Slack on PR Review | |
| runs-on: ubuntu-latest |
🧰 Tools
🪛 zizmor (1.25.2)
[info] 13-13: workflow or action definition without a name (anonymous-definition): this job
(anonymous-definition)
🤖 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/pr-in-review-notify-slack.yml at line 13, The `notify` job
in the workflow file lacks a descriptive `name` field, which reduces visibility
in GitHub Actions UI and logs. Add a `name` field to the `notify` job with a
clear, descriptive value that explains what the job does (such as notifying
Slack). This should be added as a direct property of the notify job definition
to improve workflow readability and debugging.
Source: Linters/SAST tools
| if: | | ||
| !github.event.pull_request.draft && | ||
| !contains(github.event.pull_request.labels.*.name, 'dependencies') && | ||
| github.event.requested_reviewer.type != 'Bot' && | ||
| github.event.review.user.type != 'Bot' |
There was a problem hiding this comment.
Critical: Job guard conditions reference event fields that may not exist.
The if condition on lines 18–19 accesses context fields that don't exist in all triggering events:
- Line 18:
github.event.requested_reviewer.type != 'Bot'only exists onpull_requestevents withreview_requestedtype; undefined onpull_request_reviewevents. - Line 19:
github.event.review.user.type != 'Bot'only exists onpull_request_reviewevents; undefined onpull_requestevents.
In GitHub Actions, evaluating undefined != 'Bot' as a boolean condition is falsy, so the job may silently skip when it should run (or vice versa depending on how null coercion is handled).
🔧 Proposed fix
if: |
!github.event.pull_request.draft &&
!contains(github.event.pull_request.labels.*.name, 'dependencies') &&
- github.event.requested_reviewer.type != 'Bot' &&
- github.event.review.user.type != 'Bot'
+ (github.event.requested_reviewer.type != 'Bot' || github.event.review.user.type != 'Bot')This uses OR logic: at least one bot check must pass (since one field will be null in any given event).
Alternatively, guard by event type first:
if: |
!github.event.pull_request.draft &&
!contains(github.event.pull_request.labels.*.name, 'dependencies') &&
!contains(github.event.pull_request.labels.*.name, 'ignore-for-release') &&
+ (github.event_name == 'pull_request' && github.event.requested_reviewer.type != 'Bot' ||
+ github.event_name == 'pull_request_review' && github.event.review.user.type != 'Bot')📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| if: | | |
| !github.event.pull_request.draft && | |
| !contains(github.event.pull_request.labels.*.name, 'dependencies') && | |
| github.event.requested_reviewer.type != 'Bot' && | |
| github.event.review.user.type != 'Bot' | |
| if: | | |
| !github.event.pull_request.draft && | |
| !contains(github.event.pull_request.labels.*.name, 'dependencies') && | |
| (github.event.requested_reviewer.type != 'Bot' || github.event.review.user.type != 'Bot') |
🤖 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/pr-in-review-notify-slack.yml around lines 15 - 19, The if
condition evaluates fields that may not exist depending on which event triggered
the workflow. The github.event.requested_reviewer.type field only exists on
pull_request review_requested events, while github.event.review.user.type only
exists on pull_request_review events. This causes undefined field access and
incorrect boolean evaluation. Fix this by refactoring the condition to either
use OR logic between the two bot type checks (allowing at least one to pass
since one will always be null) or by first checking the event type to determine
which bot field is safe to access, ensuring the job only runs when appropriate
regardless of which event type triggered the workflow.
Add 'ignore-for-release' filter for consistency.
Unlike pr-opened-notify-slack.yml (line 18), this workflow lacks the !contains(..., 'ignore-for-release') check. If a PR is labeled 'ignore-for-release' and a reviewer is requested or a review is submitted, this workflow will still trigger and send a Slack notification. For consistency across all PR lifecycle workflows and to respect the PR's release exemption, add this filter.
✅ Proposed addition
if: |
!github.event.pull_request.draft &&
!contains(github.event.pull_request.labels.*.name, 'dependencies') &&
+ !contains(github.event.pull_request.labels.*.name, 'ignore-for-release') &&
(github.event.requested_reviewer.type != 'Bot' || github.event.review.user.type != 'Bot')🤖 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/pr-in-review-notify-slack.yml around lines 15 - 19, The
workflow is missing a filter check that exists in pr-opened-notify-slack.yml for
consistency. In the if condition block that currently checks for draft status,
dependencies label, and bot types, add a new check using contains() to filter
out pull requests labeled with 'ignore-for-release'. This check should be added
as an additional condition with the logical AND operator
(!contains(github.event.pull_request.labels.*.name, 'ignore-for-release')) to
ensure that PRs marked for release exemption do not trigger Slack notifications
when reviewers are requested or reviews are submitted.
| permissions: | ||
| pull-requests: read |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial | 💤 Low value
Add explanatory comment to permissions block.
The pull-requests: read permission lacks documentation on its necessity. This makes the purpose of the permission less clear to future maintainers.
📝 Proposed comment addition
# Minimum permissions needed
permissions:
+ # Used to read PR details (title, body, labels) for filtering and notifications
pull-requests: read🧰 Tools
🪛 zizmor (1.25.2)
[warning] 9-9: permissions without explanatory comments (undocumented-permissions): needs an explanatory comment
(undocumented-permissions)
🤖 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/pr-opened-notify-slack.yml around lines 8 - 9, The
permissions block containing pull-requests: read lacks documentation explaining
why this permission is necessary. Add an explanatory comment above or inline
with the pull-requests: read permission statement in the permissions block to
clarify what this permission is used for and why it is required by the workflow.
This will help future maintainers understand the purpose and necessity of
granting this permission.
Source: Linters/SAST tools
| pull-requests: read | ||
|
|
||
| jobs: | ||
| notify: |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial | 💤 Low value
Add an explicit name to the job for better workflow visibility.
The job lacks a descriptive name field. Named jobs improve readability in GitHub Actions UI and run logs, making it easier to identify the job's purpose at a glance.
✨ Proposed addition
jobs:
notify:
+ name: Notify Slack on PR Open/Review
runs-on: ubuntu-latest🧰 Tools
🪛 zizmor (1.25.2)
[info] 12-12: workflow or action definition without a name (anonymous-definition): this job
(anonymous-definition)
🤖 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/pr-opened-notify-slack.yml at line 12, The `notify` job in
the workflow file is missing an explicit `name` field, which reduces visibility
in the GitHub Actions UI. Add a `name` field to the `notify` job with a
descriptive value that clearly indicates the job's purpose, such as notifying
Slack when a pull request is opened. This will improve readability in workflow
run logs and make it easier to identify the job's purpose at a glance.
Source: Linters/SAST tools
| - name: Resolve PR creator → Slack user ID | ||
| id: slack | ||
| env: | ||
| GITHUB_USER: ${{ github.event.pull_request.user.login }} | ||
| GITHUB_TO_SLACK: ${{ vars.SLACK_TO_GITHUB }} | ||
| run: | | ||
| SLACK_ID=$(echo "$GITHUB_TO_SLACK" | jq -r --arg user "$GITHUB_USER" \ | ||
| '.[] | select(.github == $user) | .slack') | ||
|
|
||
| if [ -z "$SLACK_ID" ]; then | ||
| echo "::warning::GitHub user '$GITHUB_USER' not found in SLACK_TO_GITHUB variable. Posting without Slack mention." | ||
| fi | ||
|
|
||
| echo "user_id=$SLACK_ID" >> $GITHUB_OUTPUT |
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial | ⚡ Quick win
Clarify variable naming: org variable SLACK_TO_GITHUB vs. env var GITHUB_TO_SLACK.
Line 42 maps organization variable vars.SLACK_TO_GITHUB to environment variable GITHUB_TO_SLACK. This naming asymmetry is confusing—the variable name suggests a Slack→GitHub mapping, but the usage pattern and environment variable name suggest the opposite. While functionally correct (assuming the org variable contains objects with both .github and .slack properties), this inconsistency can mislead future maintainers.
Consider renaming the environment variable to match the org variable name for clarity:
🔄 Proposed clarification
- name: Resolve PR creator → Slack user ID
id: slack
env:
GITHUB_USER: ${{ github.event.pull_request.user.login }}
- GITHUB_TO_SLACK: ${{ vars.SLACK_TO_GITHUB }}
+ SLACK_TO_GITHUB: ${{ vars.SLACK_TO_GITHUB }}
run: |
- SLACK_ID=$(echo "$GITHUB_TO_SLACK" | jq -r --arg user "$GITHUB_USER" \
+ SLACK_ID=$(echo "$SLACK_TO_GITHUB" | jq -r --arg user "$GITHUB_USER" \
'.[] | select(.github == $user) | .slack')Alternatively, if your org's variable name is misleading, rename it in organization settings to GITHUB_TO_SLACK for clarity.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - name: Resolve PR creator → Slack user ID | |
| id: slack | |
| env: | |
| GITHUB_USER: ${{ github.event.pull_request.user.login }} | |
| GITHUB_TO_SLACK: ${{ vars.SLACK_TO_GITHUB }} | |
| run: | | |
| SLACK_ID=$(echo "$GITHUB_TO_SLACK" | jq -r --arg user "$GITHUB_USER" \ | |
| '.[] | select(.github == $user) | .slack') | |
| if [ -z "$SLACK_ID" ]; then | |
| echo "::warning::GitHub user '$GITHUB_USER' not found in SLACK_TO_GITHUB variable. Posting without Slack mention." | |
| fi | |
| echo "user_id=$SLACK_ID" >> $GITHUB_OUTPUT | |
| - name: Resolve PR creator → Slack user ID | |
| id: slack | |
| env: | |
| GITHUB_USER: ${{ github.event.pull_request.user.login }} | |
| SLACK_TO_GITHUB: ${{ vars.SLACK_TO_GITHUB }} | |
| run: | | |
| SLACK_ID=$(echo "$SLACK_TO_GITHUB" | jq -r --arg user "$GITHUB_USER" \ | |
| '.[] | select(.github == $user) | .slack') | |
| if [ -z "$SLACK_ID" ]; then | |
| echo "::warning::GitHub user '$GITHUB_USER' not found in SLACK_TO_GITHUB variable. Posting without Slack mention." | |
| fi | |
| echo "user_id=$SLACK_ID" >> $GITHUB_OUTPUT |
🤖 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/pr-opened-notify-slack.yml around lines 38 - 51, The
organization variable `vars.SLACK_TO_GITHUB` is named misleadingly—the data
structure and jq query indicate it contains mappings of GitHub users to Slack
IDs (a GitHub→Slack mapping), not the reverse. Rename the organization variable
from `SLACK_TO_GITHUB` to `GITHUB_TO_SLACK` in your organization settings to
accurately reflect the data direction. Then update the environment variable
assignment on line 42 where `vars.SLACK_TO_GITHUB` is referenced to use
`vars.GITHUB_TO_SLACK` instead, and rename the environment variable
`GITHUB_TO_SLACK` to match the org variable name for consistency.
2 participants
Adds the 3 Slack workflows for PR opened, in-review, and closed events. Uses org-level secrets/variables.
Summary by CodeRabbit