[guillaume-dequenne]

Part of CLP-897; tracked by CLP-994.

Split Maven build/test/deploy from NEXT analysis so a failed analysis can be rerun using the producer's seven-day build artifact. The producer explicitly enables coverage; the consumer restores the output and reuses the same build number with build-maven@v2 scanner-only mode, released in 2.3.0.

Analysis runs on PRs, the default branch, maintenance branches and long-lived feature branches, matching the shared action's scan policy. Promotion requires successful build/QA dependencies and successful analysis where it runs, while accepting an intentional analysis skip on other refs. Producer and consumer use the same toolchain setup.

Validation: rebased onto current master (October 9), with no merge commits, checked the workflow YAML and diff whitespace, and exercised branch and promotion conditions across PR, main, maintenance, long-lived feature, dogfood, merge-queue and dispatch scenarios, including failures, skipped analysis and cancellation. The rebased tree matches the previously verified tree exactly. Latest-commit CI passed: Build and SCA Check.

Integrates the existing notification PR #140, with original commit authorship preserved. Notifications depend on build, analysis and promotion, so analysis failures remain visible after the split.

[hashicorp-vault-sonar-prod]

CLP-994

[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

[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

[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

[mary-georgiou]

LGTM

[gitar-bot]

Code Review 👍 Approved with suggestions 2 closed / 3 findings

🟡 Medium risk · Splitting Maven build and NEXT analysis around uploaded artifacts changes promotion gating; artifact or job-condition errors could block valid releases or permit unscanned promotion.

Splits the Maven build, test, and deploy from NEXT analysis so a failed analysis can be rerun against the producer's seven-day build artifact, using build-maven@v2 scanner-only mode with the shared build number. Resolved this session: the analysis job now pins the same mise version as the build job, and analysis failures are included in the shared Slack notification.

• Open suggestion: the PR description still says build-number claims use the PR base commit, but build-maven@v2 points the ref at the PR merge commit (GITHUB_SHA) instead, so the description should be updated.
• Also confirm that the shared action handles PRs that edit .github/workflows files without failing, since the removed Claim PR build number step previously covered that case in .github/workflows/build.yml.

💡 Quality: PR description still says build-number claims use the PR base commit

📄 .github/workflows/build.yml:29-34

This commit removes the Claim PR build number step, which pointed the build-number ref at github.event.pull_request.base.sha. On PRs, the number is now claimed by build-maven@v2, which calls get-build-number internally. That action points the ref at the ambient GITHUB_SHA, which is the PR merge commit, and has no option to use the base commit. The PR description still says "PR build-number claims use the existing base commit as the bookkeeping ref target", so it now describes behaviour the workflow no longer has. Also, the deleted comment's concern (creating refs that contain workflow changes) is no longer handled for PRs that edit .github/workflows. Please update the description to match the new behaviour, or confirm that the shared action handles PRs that edit workflow files without failing.

✅ 2 closed

✅ Quality: Analysis job pins stale mise version 2026.9.11 vs 2026.9.13

📄 .github/workflows/build.yml:59-61 📄 .github/workflows/build.yml:29-31
The new analysis job pins jdx/mise-action to version: 2026.9.11. The build job (line 31) and unified-dogfooding.yml both use 2026.9.13, which master moved to in e59ce98 (#141). The analysis job was copied from before that bump. As a result, the producer and consumer jobs install toolchains with different mise versions, and later bumps of the build job can leave this one behind. Fix: pin the analysis job to the same 2026.9.13 version.

✅ Cross-PR: Analysis failures won't trigger #140's Slack alert after split

📄 .github/workflows/build.yml:50-56 📄 .github/workflows/build.yml:78-87
This PR moves NEXT analysis out of build into a separate analysis job (head e21083f). promote runs only if needs.analysis.result is success or skipped. PR #140 (head 28b2029) adds notify-build-failure with needs: [build, promote] and if: always() && <master/branch-*/dogfood-*> && contains(needs.*.result, 'failure').

Suppose analysis fails on master or a branch-* push. build is then success, and promote's if evaluates to false, so promote is skipped. None of the jobs the notify job depends on reports failure, so no Slack alert is sent. Before the split, a failed analysis failed build, which would have triggered the alert.

This only happens if both PRs merge into master and #140's notify job still lists only build and promote in needs. Whichever PR merges second should add analysis to the notify job's needs.

🤖 Prompt for agents

Code Review: Splits the Maven build, test, and deploy from NEXT analysis so a failed analysis can be rerun against the producer's seven-day build artifact, using `build-maven@v2` scanner-only mode with the shared build number. Resolved this session: the analysis job now pins the same mise version as the build job, and analysis failures are included in the shared Slack notification.
  
  - Open suggestion: the PR description still says build-number claims use the PR base commit, but `build-maven@v2` points the ref at the PR merge commit (`GITHUB_SHA`) instead, so the description should be updated.
  - Also confirm that the shared action handles PRs that edit `.github/workflows` files without failing, since the removed `Claim PR build number` step previously covered that case in `.github/workflows/build.yml`.

1. 💡 Quality: PR description still says build-number claims use the PR base commit
   Files: .github/workflows/build.yml:29-34

   This commit removes the `Claim PR build number` step, which pointed the build-number ref at `github.event.pull_request.base.sha`. On PRs, the number is now claimed by `build-maven@v2`, which calls `get-build-number` internally. That action points the ref at the ambient `GITHUB_SHA`, which is the PR merge commit, and has no option to use the base commit. The PR description still says "PR build-number claims use the existing base commit as the bookkeeping ref target", so it now describes behaviour the workflow no longer has. Also, the deleted comment's concern (creating refs that contain workflow changes) is no longer handled for PRs that edit `.github/workflows`. Please update the description to match the new behaviour, or confirm that the shared action handles PRs that edit workflow files without failing.

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}