CLP-1061: Use common slack notification action

[mary-georgiou]

CLP-1061

Replaces the check_suite-based Slack notification workflow with a new notify-build-failure job inside build.yml, calling the shared slack-notify composite action directly from the workflow whose failure it reports.

Preserves the squad-corelang-notifs Slack channel from the old setup; branch-patterns set to master,branch-*,dogfood-* to match this repo's actual protected/CI branches.

[hashicorp-vault-sonar-prod]

CLP-1061

[gitar-bot]

⚠️ [cross-pr] notify-build-failure needs misses #588's new scan job

This PR (#597, head 6cc1976) hardcodes needs: [build, build-win, qa, promote] and gates the job on contains(needs.*.result, 'failure'). PR #588 (head 82efc48) adds a new scan job (needs: build) and changes promote.needs to [build, scan, build-win, qa]; I checked this in its build.yml at lines 57-59 and 186-191. The problem only appears if both PRs land on master and nobody updates the notifier's needs list, whichever merges first. In that case, when scan fails, promote is skipped rather than failed, so none of the listed results is 'failure'. The notifier then never runs, and a failed NEXT analysis on master, branch-* or dogfood-* sends no Slack alert. The notifier still waits for scan indirectly through promote, but it cannot see that scan failed.

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

[gitar-bot]

Code Review ⚠️ Changes requested 1 closed / 2 findings

🟡 Medium risk · Adds a failure-notification job with workflow permissions and a shared Slack action.

Migrates Slack notifications to use the shared slack-notify action and makes branch patterns dynamic. However, the notify-build-failure job's hardcoded needs list omits the new scan job from PR #588, so failures in that job won't trigger alerts on master or protected branches.

⚠️ [cross-pr] notify-build-failure needs misses #588's new scan job

📄 .github/workflows/build.yml:168-172

This PR (#597, head 6cc1976) hardcodes needs: [build, build-win, qa, promote] and gates the job on contains(needs.*.result, 'failure'). PR #588 (head 82efc48) adds a new scan job (needs: build) and changes promote.needs to [build, scan, build-win, qa]; I checked this in its build.yml at lines 57-59 and 186-191. The problem only appears if both PRs land on master and nobody updates the notifier's needs list, whichever merges first. In that case, when scan fails, promote is skipped rather than failed, so none of the listed results is 'failure'. The notifier then never runs, and a failed NEXT analysis on master, branch-* or dogfood-* sends no Slack alert. The notifier still waits for scan indirectly through promote, but it cannot see that scan failed.

✅ 1 closed

✅ Quality: Job if still hardcodes master after branch-patterns went dynamic

📄 .github/workflows/build.yml:169-172 📄 .github/workflows/build.yml:182
This commit swaps the hardcoded master in branch-patterns for github.event.repository.default_branch. The notify-build-failure job's if gate on line 171 still checks github.ref == 'refs/heads/master'. Right now both resolve to master, so nothing breaks yet. But if the default branch is ever renamed (for example to main), the dynamic pattern would match it while the job-level gate stays false. The job would be skipped and default-branch failures would never reach Slack, which undoes the point of the change. Use the same expression in the if so the two filters can't drift apart. The push.branches trigger can't take expressions, so it has to stay hardcoded.

🤖 Prompt for agents

Code Review: Migrates Slack notifications to use the shared `slack-notify` action and makes branch patterns dynamic. However, the `notify-build-failure` job's hardcoded `needs` list omits the new `scan` job from PR #588, so failures in that job won't trigger alerts on master or protected branches.

1. ⚠️ [cross-pr] notify-build-failure needs misses [#588](<https://github.com/SonarSource/sonar-xml/pull/588>)'s new scan job
   Files: .github/workflows/build.yml:168-172

   This PR (https://github.com/SonarSource/sonar-xml/pull/597, head 6cc19764aa19800979f22053ca13ae0f6cbbba20) hardcodes `needs: [build, build-win, qa, promote]` and gates the job on `contains(needs.*.result, 'failure')`. PR https://github.com/SonarSource/sonar-xml/pull/588 (head 82efc487e7a103c09f1f29e1191a93ef043d1dd0) adds a new `scan` job (`needs: build`) and changes `promote.needs` to `[build, scan, build-win, qa]`; I checked this in its build.yml at lines 57-59 and 186-191. The problem only appears if both PRs land on master and nobody updates the notifier's needs list, whichever merges first. In that case, when `scan` fails, `promote` is skipped rather than failed, so none of the listed results is 'failure'. The notifier then never runs, and a failed NEXT analysis on master, branch-* or dogfood-* sends no Slack alert. The notifier still waits for `scan` indirectly through `promote`, but it cannot see that `scan` failed.

Review coverage

🧪 Functional validation 1 of 1 objectives covered

📋 Rules No rules evaluated

🤖 Auto-approval Not enabled · Set up

Implementation Status ✅ 1 of 1 objectives covered

✅ CLP-1061 - 1 of 1 objectives covered

This PR covers the replacement of the slack workflow file with the shared common slack notification action.

✅ 1 covered here

• ✅ Replace .github/workflows/slack_notify.yml with the shared common slack notification action

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Counting what did not apply, without listing it.
Unblock → Override a blocking verdict and allow merging.

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

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

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

[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