[guillaume-dequenne]

Part of CLP-900

Give the Linux and Windows build jobs sole ownership of their Maven caches. QA jobs restore the cache without saving it, and the shared Maven actions no longer write a second cache for the same repository.

Validation: PR CI passed, and Linux build, QA, and Windows build restored exact Maven cache keys. In the last 30 days, 9 of 52 commits touched a POM. The new default-branch writer behavior can only be measured when the workflow runs on master.

[hashicorp-vault-sonar-prod]

CLP-1116

[github-actions]

Ruling Report

✅ No changes to ruling expected issues in this PR

[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 2 closed / 2 findings

🟡 Medium risk · Changes Maven cache ownership and keys across build and QA workflows.

Fixes Maven cache key identity by giving Linux and Windows build jobs sole ownership of their caches, preventing QA jobs from inadvertently overwriting them. Resolves IT-only dependencies being saved to cache and the maven_cache anchor conflict from #857.

✅ 2 closed

✅ Performance: IT-only Maven dependencies are no longer saved to any cache

📄 .github/workflows/build.yml:78-84 📄 .github/workflows/build.yml:94-102 📄 .github/workflows/build.yml:114-121 📄 .github/workflows/build.yml:138-146 📄 .github/workflows/build.yml:267-273 📄 .github/actions/maven-cache/action.yml:21-35
After this change, only build and build-windows save ~/.m2/repository. They build the root reactor, which contains only sonar-html-plugin (pom.xml:46-48; its is only added by a profile). The qa, qa-dev and ruling jobs run mvn -f its/pom.xml / its/ruling/pom.xml, which pull Orchestrator, SonarLint and other IT dependencies. Those jobs now restore only, and config-maven has disable-caching: 'true', so none of those dependencies are saved anywhere. The same applies to analyze-shadows with -Pcoverage-report. The exact-key hit these jobs get is on a cache that doesn't contain their dependencies, so every run downloads the full IT tree from Artifactory, even on master. Before this PR, the QA jobs' actions/cache step and config-maven's own cache on master could still save them. One fix is to give the IT jobs their own owned cache (for example a separate maven-its-<os>-… key saved by qa). Another is to have the build job resolve IT dependencies (for example mvn -f its/pom.xml dependency:go-offline) before its cache is saved.

✅ Cross-PR: #857's maven_cache anchor conflicts with the new opt-in save contract

📄 .github/workflows/build.yml:30-32 📄 .github/workflows/build.yml:55-57 📄 .github/workflows/build.yml:78-79 📄 .github/actions/maven-cache/action.yml:4-7 📄 .github/actions/maven-cache/action.yml:21-35
This PR (#874, head b977702) adds a save input to .github/actions/maven-cache that defaults to 'false'. The action now writes the cache only when a caller passes save: 'true' on the default branch (action.yml:21-35). It also moves the &maven_cache anchor from the build job to the qa job (build.yml:78). PR #857 at head 486082c still defines &maven_cache with no save input in build (its build.yml:32). It reuses that anchor as *maven_cache in its new scan job (line 70), build-windows (89), qa, qa-dev, ruling and analyze-shadows.

If #857 merges after #874, or is rebased onto it, the two edits to the build job conflict, and each way of resolving it breaks something:

• Keeping CLP-988 Split build from analysis for sonar-html #857's anchor means no job passes save: 'true'. Every Maven cache write on master stops without any error.
• Keeping Fix cache key identity for SonarHTML #874's layout leaves CLP-988 Split build from analysis for sonar-html #857's scan job (and any other job before qa) referring to *maven_cache before the anchor is defined. That is an undefined YAML alias, so GitHub rejects the whole workflow file.

This only happens when both PRs land. The lost cache writes show up only on default-branch runs.

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}