ci: in-process SpotBugs + changed-modules-only reactor in the spotbugs lane

[joaodinissf]

Note

Stacked on #1400. Earlier commits belong to #1399/#1396/#1400; review only the last two commits here.

Two reductions to the spotbugs lane, the verify pipeline's critical path (~8.5 min full scan):

1. -Dspotbugs.fork=false — the plugin forks a fresh 2 GB JVM per module by default (59 forks per full scan). Analysis now runs inside the Maven JVM; the lane's MAVEN_OPTS: -Xmx4g governs the shared heap. Findings are identical (59 module SARIFs, same result count).
2. Scoped reactor with a pinned target definition and presence-gated results — compute-spotbugs-skip.sh additionally exports SPOTBUGS_SCOPE_ARGS (-pl ../ddk-target,<changed modules> -am), so a scoped run builds only the PR's changed modules plus their upstream dependencies instead of the full 64-module reactor; the -am-pulled unchanged dependencies keep the injected spotbugs.skip (they compile for the aux-classpath but are not analysed). ddk-target is pinned into every scoped reactor because the target-definition artifact is referenced by target-platform-configuration, not by any MANIFEST — without the pin, Tycho falls back to a local-repository copy of the .target, which fails on a cold cache and can silently resolve a stale target definition on a warm one (observed: an installed June copy of the same sequenceNumber still pointed at the 2026-03 release train). The gate verifies every scanned source-bearing module produced its SARIF (plus any-SARIF on full scans): --fail-never swallows even target-resolution failures, so without the presence check a dead build counts zero violations and passes vacuously. When no reactor module changed at all (e.g. a docs-only PR) the lane skips the Maven invocation and the SARIF upload entirely (SPOTBUGS_KEPT=0); the fail-safe full-scan path exports KEPT=all, because an unset variable coerces equal to '0' in the workflow if: expression and would wrongly skip the build. Fail-safes otherwise unchanged: build/config changes and master/snapshot builds get a full reactor and full scan.

Measurements

Regime	Before	After	Δ
Full scan, warm cache (this PR's runs vs the same-base #1396/#1400 runs)	492–553s / 548–553s same-base	307–401s across runs (latest same-base: 307s vs 548s)	~−30–45%
Scoped run, one changed module, cold cache (fork probes, ddk-target pinned, analysis verified present)	165s (skip-only)	97–135s across runs (final-SHA runs 97–110s)	−18–41%
Docs-only PR, no reactor module changed (fork probe)	165s (skip-only full compile)	9–13s	−92%

Local (clean tree, JDK 21, warm cache): full scan 75s vs 95s; scoped 34s vs 75s with the pinned reactor resolving the current platform (jdt.core 3.46.0). An earlier probe's 40s scoped figure was vacuous — the run had silently failed target resolution and analysed nothing, which is exactly the hole the presence gate closes.

Tycho -pl/-am verification (local, exhaustive)

• Reactor closure: for each of the 59 non-pom modules, the -pl <module> -am reactor was compared against a MANIFEST-derived ground-truth closure (Require-Bundle + Fragment-Host + Import-Package→Export-Package). 59/59 covered, including the four test fragments and the Import-Package-wired test bundle.
• Loud failure by construction: ddk.target contains no DDK p2 repository, so a missing -am edge cannot be satisfied by a stale published DDK bundle — resolution fails hard (and the presence gate catches even a swallowed failure).
• Behavioral equivalence: for the deepest modules (xtext.test, check.ui.test, xtext.format), SpotBugs' FindBugsSummary (analyzed/referenced classes, size, packages) is identical between full-reactor and scoped runs; with the ddk-target pin the resolved third-party platform-bundle versions match exactly as well.

Merge chain: #1399 (merged) → #1396 → #1400 → #1456 (this PR) → #1457 → #1397

🤖 Generated with Claude Code