[mary-georgiou]

CLP-1040: adopt the shared slack-notify composite action for build-failure notifications.

Adds a notify-build-failure job to build.yml (runs after build/promote/promote-nuget/promote-npm on failure for master, branch-*, dogfood-on-*), replacing the old draft's check_suite-triggered workflow, which is removed since that event never fires for GitHub Actions' own runs.

Notifies squad-corelang-notifs (channel from the previous draft, no prior working mechanism existed) with branch-patterns: 'master,branch-*,dogfood-on-*' to match this repo's push triggers.

[hashicorp-vault-sonar-prod]

CLP-1040

[gitar-bot]

💡 [cross-pr] Notify job misses the scan job that PR #542 adds

This PR (head faf53b1) adds notify-build-failure with needs: [ build, promote, promote-nuget, promote-npm ], and it only fires when contains(needs.*.result, 'failure'). PR #542 (head 24f9c3d) moves Sonar analysis out of build into a new scan job and changes all three promote jobs to needs: [ build, scan ]. Suppose both PRs merge into build.yml on master, in either order, and nobody adds scan to the notifier's needs. Then a failure in scan alone leaves build green and the promote jobs skipped rather than failure. The contains check stays false and no Slack alert is sent, even though the master/branch pipeline failed.

_{Was this helpful? React with 👍 / 👎}

✅ All blocking issues resolved.

_{Configure merge blocking}

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube

[gitar-bot]

Code Review 👍 Approved with suggestions 2 closed / 3 findings

🟡 Medium risk · Adds a failure-triggered CI notification job with job-scoped token permissions

Adopts the shared slack-notify action for build-failure notifications on master, branch-*, and dogfood-on-* branches, replacing the non-functional check_suite trigger. The notify-build-failure job's needs list should include the scan job added in PR #542 to catch scan-only failures; otherwise a scan failure alone will skip notification when other jobs remain green.

💡 [cross-pr] Notify job misses the scan job that PR #542 adds

📄 .github/workflows/build.yml:361-365

This PR (head faf53b1) adds notify-build-failure with needs: [ build, promote, promote-nuget, promote-npm ], and it only fires when contains(needs.*.result, 'failure'). PR #542 (head 24f9c3d) moves Sonar analysis out of build into a new scan job and changes all three promote jobs to needs: [ build, scan ]. Suppose both PRs merge into build.yml on master, in either order, and nobody adds scan to the notifier's needs. Then a failure in scan alone leaves build green and the promote jobs skipped rather than failure. The contains check stays false and no Slack alert is sent, even though the master/branch pipeline failed.

✅ 2 closed

✅ Bug: check_suite trigger never fires for this repo's GitHub Actions CI

📄 .github/workflows/slack-notify.yml:3-5 📄 .github/workflows/slack-notify.yml:20-21 🔗 link
All of this repo's CI runs on GitHub Actions (.github/workflows/build.yml, and there's no Cirrus or other external CI config). The GitHub docs say the check_suite event does not trigger workflows when "the check suite was created by GitHub Actions or if the check suite's head SHA is associated with GitHub Actions" (events that trigger workflows). That rule exists to stop workflows from triggering each other in a loop. So when the Build workflow fails on master, this workflow is never triggered, and no Slack notification is sent. The PR's main goal of adding failure notifications isn't met.

Fix: trigger on workflow_run for the Build workflow, filtered to the notified branches, and take the branch and conclusion from github.event.workflow_run.

✅ Quality: Job if still hardcodes 'master' while branch-patterns uses default_branch

📄 .github/workflows/build.yml:362-365 📄 .github/workflows/build.yml:376
This commit swaps the hardcoded master in branch-patterns for github.event.repository.default_branch, but the job's if gate on line 364 still checks github.ref_name == 'master'. The two filters now disagree. If the default branch is ever renamed (to main, say), the gate skips the job before the action runs, so default-branch failures stop producing notifications and the dynamic pattern never gets used. Build the gate from the same expression so both filters stay in sync.

🤖 Prompt for agents

Code Review: Adopts the shared `slack-notify` action for build-failure notifications on `master`, `branch-*`, and `dogfood-on-*` branches, replacing the non-functional `check_suite` trigger. The `notify-build-failure` job's `needs` list should include the `scan` job added in PR #542 to catch scan-only failures; otherwise a `scan` failure alone will skip notification when other jobs remain green.

1. 💡 [cross-pr] Notify job misses the `scan` job that PR [#542](<https://github.com/SonarSource/sonar-analyzer-commons/pull/542>) adds
   Files: .github/workflows/build.yml:361-365

   This PR (head faf53b17a56d305f2967bdcb1dd2f8265f92d83b) adds `notify-build-failure` with `needs: [ build, promote, promote-nuget, promote-npm ]`, and it only fires when `contains(needs.*.result, 'failure')`. PR https://github.com/SonarSource/sonar-analyzer-commons/pull/542 (head 24f9c3dbe0851e29a5ef26c6afe17a4142f09423) moves Sonar analysis out of `build` into a new `scan` job and changes all three promote jobs to `needs: [ build, scan ]`. Suppose both PRs merge into build.yml on master, in either order, and nobody adds `scan` to the notifier's `needs`. Then a failure in `scan` alone leaves `build` green and the promote jobs `skipped` rather than `failure`. The `contains` check stays false and no Slack alert is sent, even though the master/branch pipeline failed.

Verification

Functional validation No results

Rules No rules evaluated

Auto-approval Not enabled

Set up

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Counting what did not apply, without listing it.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}