Skip to content

notify slack and triage labels #2211

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
ofek1weiss merged 2 commits into from
Apr 26, 2026
+55 −22
Merged

notify slack and triage labels #2211

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
a2e9221
notify slack and triage labels
ofek1weiss Apr 26, 2026
7553c24
Merge branch 'master' into app-1004-triage-labels-notify-slack
ofek1weiss Apr 26, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
55 changes: 36 additions & 19 deletions .github/workflows/notify_slack.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -12,17 +12,23 @@ on:
type: string
required: true

permissions: {}

jobs:
print_inputs:
timeout-minutes: 2
name: print inputs
runs-on: ubuntu-latest
steps:
- name: print
env:
RUN_ID: ${{ inputs.run_id }}
WORKFLOW_NAME: ${{ inputs.workflow_name }}
RESULT: ${{ inputs.result }}
run: |
echo "${{ inputs.run_id }}"
echo "${{ inputs.workflow_name }}"
echo "${{ inputs.result }}"
echo "$RUN_ID"
echo "$WORKFLOW_NAME"
echo "$RESULT"

notify:
name: Notify Slack Failure
Expand All @@ -31,21 +37,32 @@ jobs:
if: ${{ inputs.result == 'failure' }}
steps:
- name: Slack Notification
uses: tokorom/action-slack-incoming-webhook@main
env:
INCOMING_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
with:
text: Scheduled Run Failed - ${{ inputs.workflow_name }}
attachments: |
[
{
"color": "danger",
"fields":
[
{
"title": "URL:",
"value": "${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ inputs.run_id }}"
}
SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}
WORKFLOW_NAME: ${{ inputs.workflow_name }}
RUN_URL: ${{ github.server_url }}/${{ github.repository }}/actions/runs/${{ inputs.run_id }}
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot Apr 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

run_id is treated as required at runtime but optional in inputs.

Line 43 always builds RUN_URL from inputs.run_id. If callers omit it, Slack gets a broken run link. Either make run_id required or add explicit fallback/guard logic.

Proposed fix (make input contract explicit) 
 on:
   workflow_call:
     inputs:
       run_id:
         type: string
-        required: false
+        required: true
🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In @.github/workflows/notify_slack.yml at line 43, The workflow always
constructs RUN_URL using inputs.run_id but the input is optional, causing broken
links when omitted; either mark the input as required in the notify_slack.yml
inputs block (set inputs.run_id required: true) or change the RUN_URL assignment
to guarded/default behavior so it only builds when inputs.run_id exists
(fallback to github.run_id or omit the URL) — update the RUN_URL environment
entry and/or the inputs.run_id declaration accordingly to ensure a valid run
link is produced.

run: |
payload="$(
jq -n \
--arg text "Scheduled Run Failed - $WORKFLOW_NAME" \
--arg run_url "$RUN_URL" \
'{
text: $text,
attachments: [
{
color: "danger",
fields: [
{
title: "URL:",
value: $run_url
}
]
}
]
}
]
}'
)"

curl --fail --show-error --silent \
--header "Content-Type: application/json" \
--data "$payload" \
"$SLACK_WEBHOOK_URL"
22 changes: 19 additions & 3 deletions .github/workflows/triage-labels.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,23 @@ jobs:
runs-on: ubuntu-latest
steps:
- name: Update label
uses: andymckay/labeler@master
# actions/github-script v8, checked 2026-04-26.
uses: actions/github-script@ed597411d8f924073f98dfc5c65a23a2325f34cd
with:
add-labels: "Triage 👀"
remove-labels: "Awaiting Response"
script: |
const { owner, repo } = context.repo;
const issue_number = context.issue.number;

await github.rest.issues.addLabels({
owner,
repo,
issue_number,
labels: ["Triage 👀"],
});

await github.rest.issues.removeLabel({
owner,
repo,
issue_number,
name: "Awaiting Response",
});
Comment on lines +27 to +32
Copy link
Copy Markdown

@coderabbitai coderabbitai Bot Apr 26, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major

🧩 Analysis chain

🌐 Web query:

GitHub REST API: For issues.removeLabel, what status/error is returned when the target label is not present on the issue?

💡 Result:

The GitHub REST API endpoint for removing a label from an issue (DELETE /repos/{owner}/{repo}/issues/{issue_number}/labels/{name}, corresponding to issues.removeLabel in client libraries like Octokit) returns a 404 Not Found status code when the target label is not present on the issue.

Citations:

Make label removal idempotent to prevent flaky failures.

The removeLabel call will fail with a 404 if "Awaiting Response" was already removed by another workflow run or manual edit, causing the job to fail despite the desired end state being achieved. Wrap the call in a try/catch to ignore 404 errors.

Proposed patch 
             await github.rest.issues.addLabels({
               owner,
               repo,
               issue_number,
               labels: ["Triage 👀"],
             });
 
-            await github.rest.issues.removeLabel({
-              owner,
-              repo,
-              issue_number,
-              name: "Awaiting Response",
-            });
+            try {
+              await github.rest.issues.removeLabel({
+                owner,
+                repo,
+                issue_number,
+                name: "Awaiting Response",
+              });
+            } catch (error) {
+              if (error.status !== 404) throw error;
+            }
📝 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.

Suggested change
await github.rest.issues.removeLabel({
owner,
repo,
issue_number,
name: "Awaiting Response",
});
await github.rest.issues.addLabels({
owner,
repo,
issue_number,
labels: ["Triage 👀"],
});
try {
await github.rest.issues.removeLabel({
owner,
repo,
issue_number,
name: "Awaiting Response",
});
} catch (error) {
if (error.status !== 404) throw error;
}
🤖 Prompt for AI Agents 
Verify each finding against the current code and only fix it if needed.

In @.github/workflows/triage-labels.yml around lines 27 - 32, The removeLabel
call (github.rest.issues.removeLabel) can throw a 404 if the "Awaiting Response"
label is already gone; wrap the await github.rest.issues.removeLabel({ owner,
repo, issue_number, name: "Awaiting Response" }) in a try/catch and silently
ignore errors where err.status === 404 (or the Not Found message), but rethrow
all other errors so genuine failures still surface.

Loading