Fadhli Azhari
e3d9e66574
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> |
||
|---|---|---|
| .gitea/workflows | ||
| ci | ||
| .gitignore | ||
| CLAUDE.md | ||
| build-and-push.ps1 | ||