perf(ci): let the build cache reuse core-web across PR and trunk (#36947)

[wezell]

What

Makes dotcms-core-web reusable by a content-addressed build cache across PR and trunk builds. Prerequisite for #36947; the S3 cache PR is stacked on this one.

Why

core-web/pom.xml declared a profile is_pr, auto-activated by -Dgithub.event.name=pull_request, which cicd_comp_build-phase.yml passed on every build. Three of its four properties were byte-identical to the defaults directly above it:

Property	Default (line 26-28)	is_pr
git.origin.branch	origin/main	origin/main
nx.affected.options	--base=${git.origin.branch} --head=HEAD	same
pretty.quick.options	--branch=${git.origin.branch}	same
skip.validate	true	false ← the only live effect

So the profile's entire purpose was: run eslint + prettier inside the artifact build, on PRs and nowhere else.

That makes the PR effective pom differ from trunk's, and the Maven build cache hashes the effective pom — so the module can never be reused across the two. Both executions sit at generate-resources; the expensive nx run-many -t build sits at compile and doesn't depend on them. We were paying ~2.85m of rebuild to protect a check the build doesn't consume.

Worth noting: inputs.validate defaults to false and no caller overrides it, so -Pvalidate was never actually passed by PR, merge-queue, trunk or nightly. is_pr was the sole source of skip.validate=false.

Verification

Measured, not argued — cache key for dotcms-core-web:

Build shape	Key
-Dgithub.event.name=pull_request	fd879a30…
-Dgithub.event.name=push	fd879a30…
no flag	fd879a30…
-Dskip.validate=false	2b0c0b9f… ← isolates the divergence

Reproduce with ./mvnw -pl :dotcms-core-web validate -Dmaven.build.cache.enabled=true and grep the 64-hex checksum.

A latent bug this surfaced

format-test ran nx format:check with no --base, so it fell back to nx.json's "defaultBase": "main" — a local branch that only exists because a job passed require-main: true to prepare-runner, which then runs git fetch origin main:main. cicd_comp_test-phase.yml never passes it, so relocating the check would have broken every frontend PR.

Fixed by making the base explicit (origin/main, always present after a fetch-depth: 0 checkout) rather than plumbing require-main through the test phase. Confirmed: --base=origin/main → exit 0 clean; --base=does-not-exist-ref → exit 1. Invisible locally because dev machines have a local main.

Trade-off

Lint/prettier failures now surface in the Frontend Unit Tests job instead of the earlier Initial Artifact Build. That job is filter-gated on frontend, which is fine because nx affected --base=origin/main already made these no-ops on backend-only PRs.

If the later feedback is unwelcome, the alternative is a dedicated mvnw generate-resources -pl :dotcms-core-web -Pvalidate job — one extra job, still off the critical path. Happy to switch.

🤖 Generated with Claude Code

https://claude.ai/code/session_014a2iJy9JXRBSVdKBbmoZ2S

This PR fixes: #36947

This PR fixes: #36947

[claude]

Claude finished @wezell's task in 6m 26s —— View job

---

Code Review

• Read the diff against origin/main
• Review CI/workflow changes for correctness
• Review core-web/pom.xml and cache config changes
• Post findings

I traced the is_pr removal, the skip.validate default chain, the --base addition to format:check, the S3 cache wiring, and the provenance/kill-switch logic. The core reasoning in the PR body checks out against the code.

New Issues

• 🟡 Medium: .github/workflows/cicd_comp_build-phase.yml:196 — the provenance recorder relies on find "$root" -mindepth 5 -maxdepth 5 -type d -name local matching the build-cache layout. Assumption: the local cache dir sits exactly 5 levels under ~/.m2/build-cache with a leaf named local. If the maven-build-cache-extension 1.2.0 layout differs (or changes on upgrade), the loop silently matches nothing and count=0 — you'd get "Recorded provenance for 0 cache entries" with no failure, so the supply-chain audit trail is quietly empty. It's continue-on-error: true and only runs on trusted write refs, so blast radius is limited to lost provenance, not a broken build. What to verify: confirm the depth against a real trunk/merge-queue run's ~/.m2/build-cache tree and consider logging a warning when count=0 but modules were built.

• 🟡 Medium: .github/workflows/cicd_comp_build-phase.yml:137 — save is gated on github.event_name == 'push' && github.ref == 'refs/heads/main', but cicd_3-trunk.yml can also run via workflow_dispatch. On a manual trunk run event_name is workflow_dispatch, so save=false and that build won't populate the cache. Almost certainly intentional (only automatic trunk pushes populate), but worth a one-line confirmation since the trunk workflow passes the read-write key regardless. Not a correctness bug.

Everything else looks sound:

• The is_pr profile deletion is safe — three of its four properties were byte-identical to the defaults at core-web/pom.xml:25-28, and -Dgithub.event.name is referenced nowhere else in the repo (only the removed profile activated on it). Verified via grep.
• skip.validate correctly defaults to true, so lint-test/format-test are now inert unless -Pvalidate flips it to false — which test-matrix.yml now passes for the Frontend Unit Tests suite. Chain is consistent.
• The --base=${git.origin.branch} fix on format:check is correct: it resolves to origin/main (always present after fetch-depth: 0), avoiding the nx.json defaultBase: main local-branch trap that would otherwise only work on jobs passing require-main: true.
• FINAL_ARGS interpolation of ${BUILD_CACHE_ARGS:-} is null-safe, and the dedup awk pass is preserved.
• Security posture is solid: RO key on PR (untrusted), RW on merge-queue/trunk, the runtime write-probe that proves the RO key can't write, digest-pinned sigv4 proxy and actions/cache, and the 403→404 HEAD handling for the extension's miss semantics.

Re: sfreudenthaler's note on the format profile block in core-web/pom.xml — that block (<id>format</id>, the auto-format/auto-lint executions) is separate from what this PR removed and is invoked by developers locally; the trigger comment didn't ask me to touch it, so I've left it. It can be pruned in a follow-up if it's confirmed unused.

No blocking issues. The two Medium items are non-blocking.
· issue-36947-core-web-cacheable

[sfreudenthaler]

If the later feedback is unwelcome, the alternative is a dedicated mvnw generate-resources -pl :dotcms-core-web -Pvalidate job — one extra job, still off the critical path. Happy to switch.

Lets see it in action. Shouldn't be an issue, I think more folks using claude and other bots to parse the failure logs and the bots dont need pretty.

Approved with small non-blocking suggestion