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>
The image is built around corepack-activated pnpm@10.15.0 but two
install commands were still using npm/npx, which:
- Ignores the pnpm store and creates a separate npm cache (~/.npm)
- Inconsistent with the rest of the image
Replace:
- `npm install -g @bufbuild/protoc-gen-es@X` → `pnpm add -g @bufbuild/protoc-gen-es@X`
- `npx --yes playwright@X install chromium` → `pnpm dlx playwright@X install chromium`
`pnpm add -g` requires PNPM_HOME on PATH (pnpm's interactive `pnpm
setup` does this; we do it explicitly):
ENV PNPM_HOME=/root/.local/share/pnpm
ENV PATH="${PNPM_HOME}:${PATH}"
`pnpm dlx` is a transient install — fetches the package into the
store, runs the install command, leaves only the browser binary at
$PLAYWRIGHT_BROWSERS_PATH (which is what we actually want).
No functional change for consumers. Image is just self-consistent now.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
CI's frontend test-e2e job was running `pnpm exec playwright install
chromium` every time — ~170MB chromium download per run, plus the
fall-through to `actions/cache` for the browser binary which only
hides the cost when the cache backend is healthy.
Bake it into the image instead:
- New ARG PLAYWRIGHT_VERSION=1.59.1 (must match KollectAI-ETL's
frontend/svelte/package.json @playwright/test pin)
- New ENV PLAYWRIGHT_BROWSERS_PATH=/ms-playwright (constant location
Playwright respects across pnpm/npm invocations)
- New RUN: `npx --yes "playwright@${PLAYWRIGHT_VERSION}" install chromium`
System libs (libnss3, libgbm1, libasound2, etc.) were already
pre-installed at the top of the file, so we skip --with-deps. Verify
step now also lists $PLAYWRIGHT_BROWSERS_PATH contents to fail-fast
if a future bump leaves the dir empty.
KollectAI-ETL's frontend.yml drops both `Cache Playwright browsers`
and `Install Playwright browsers` steps in the matching commit on
that side. Net: image build adds ~170MB but every CI test-e2e run
saves ~30-60s (download time + cache I/O).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The 2.4.0 default crashed at runtime with
"protoc-gen-es: Cannot read properties of undefined (reading 'length')"
when buf v1.55 invoked it. 2.12.x is current and has no such issue.
KollectAI-ETL's CI no longer relies on the image's globally-installed
plugin (the proto-gen workflow now does `pnpm install` in proto/ and
runs `pnpm exec buf generate` to use the lockfile-pinned version), so
this is mainly housekeeping for ad-hoc use inside the container.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ci/frontend-builder (new): Node 24 + pnpm 10 + buf 1.55 + global
@bufbuild/protoc-gen-es 2.4 + Playwright chromium runtime libs +
ORAS. Used by KollectAI-ETL frontend CI to run TS proto codegen
locally (buf.gen.yaml uses `local: protoc-gen-es`) instead of the
rate-limited BSR remote-plugin path.
ci/java-builder: added the standalone buf binary so `buf lint` runs
in CI without an inline curl install. Backend Java codegen stays in
the Maven build (protobuf-maven-plugin), so no protoc plugins are
added to this image.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Fadhli Azhari