Currently KollectAI-ETL's sonar.yml runs in the java-builder image and
downloads sonar-scanner-cli at runtime via curl, with a separate
actions/cache step keyed on the version. That works but:
- Adds two steps (cache restore + conditional install) per scan
- Depends on the gitea-actions cache backend being healthy (the same
backend that's been timing out lately)
- Single-purpose tool with single-purpose cache plumbing
New ci/sonar-runner image extends ci/java-builder via FROM and bakes
sonar-scanner-cli at /opt/sonar-scanner with bin/ on PATH. Inherits
everything from java-builder (Java 25, Maven, Node + pnpm, buf, ORAS,
NVD database) — no duplicate state.
Build args:
- REGISTRY (default 192.168.1.72) + JAVA_BUILDER_TAG (default latest)
for the FROM line
- SONAR_SCANNER_VERSION (default 6.2.1.4610) — must match
KollectAI-ETL's sonar.yml SONAR_SCANNER_VERSION env
Build order: java-builder first, then sonar-runner. The CI workflow's
auto-discovery handles this naturally; for manual builds use
build-and-push.ps1 -Image ci/java-builder before ci/sonar-runner.
Matching change in KollectAI-ETL drops the cache-scanner-cli + install
steps from sonar.yml; the scan job just runs `sonar-scanner` directly.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Fadhli Azhari