Repository navigation
Warm Maven repository before Qodana scan - #139
Conversation
Qodana's Maven import intermittently completes in seconds without downloading dependencies (passing runs spend ~11min in the project opening stage), leaving every library root unresolved at /data/cache/.m2. The sanity check then fails on a rotating set of files and emits 54 bogus Lombok-related findings, tripping --fail-threshold 0. Master runs failed 4x in a row today (27328515558, its rerun, 27331194671, its rerun) and once on 2026-06-04 (26931814015) with this signature. Seed the exact repo path the Qodana container uses (cache-dir/.m2 -> /data/cache/.m2) via dependency:go-offline, cached on pom.xml hash, so the scan never depends on Qodana's own download step. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Qodana for JVMIt seems all right 👌 No new problems were found according to the checks applied 💡 Qodana analysis was run in the pull request mode: only the changed files were checked Contact Qodana teamContact us at qodana-support@jetbrains.com
|
There was a problem hiding this comment.
Pull request overview
This PR hardens the Qodana GitHub Actions workflow by pre-populating the Maven local repository that Qodana’s container uses, reducing intermittent dependency-resolution failures that lead to bogus “unresolved symbols” and follow-on false positives.
Changes:
- Adds JDK 25 setup to align the workflow environment with
projectJDK: "25"inqodana.yaml. - Caches and warms the Maven repo under the Qodana cache directory using
mvn dependency:go-offline. - Seeds
/data/cache/.m2(via the runner cache directory mapping) before runningJetBrains/qodana-action@v2026.1.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| - name: Cache Qodana Maven repository | ||
| uses: actions/cache@v5 | ||
| with: | ||
| path: ${{ runner.temp }}/qodana/caches/.m2 | ||
| key: ${{ runner.os }}-qodana-m2-${{ hashFiles('**/pom.xml') }} | ||
| restore-keys: | | ||
| ${{ runner.os }}-qodana-m2- |
There was a problem hiding this comment.
Addressed in eae6368 — disabled the action's built-in caching (use-caches: false, which also makes cache-default-branch-only moot). Its per-SHA keys never restored in the runs we inspected, so the only effect would have been re-uploading the seeded .m2 every run. The explicit pom-keyed actions/cache step is now the sole cache manager.
Its per-SHA cache keys never restored in practice, and with the pre-seeded .m2 it would re-upload a large cache every run. The explicit actions/cache step keyed on pom.xml manages the Maven repo instead. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The linter bump in #138 did not fix the recurring master Qodana failures — runs 27328515558 and 27331194671 (and their reruns) all failed with the same signature, as did 26931814015 on 2026-06-04.
Root cause: Qodana's own Maven import intermittently completes without downloading dependencies. Failing runs finish the project opening stage in 26–37s vs 11m 33s in passing runs, and log
Roots jar:///data/cache/.m2/... were not resolvedfor every library. With an unresolved classpath the sanity check fails on a rotating set of files (20 Critical "Java sanity" problems) and annotation processing misfires, producing 54 bogus findings ("Field may be 'final'" ×35, "Field can be local variable" ×16, …) that trip--fail-threshold 0.Fix: seed the exact Maven repo path the Qodana container uses (
<cache-dir>/.m2→/data/cache/.m2) withmvn dependency:go-offlinebefore the scan, cached onpom.xmlhash, so the analysis never depends on Qodana's flaky download step.🤖 Generated with Claude Code