platform/ci-images

CI job base images for the Adibilis Forgejo Actions runners. Public and secret-free by design — see "Why public" below.

Images

Tag	Dockerfile	Consumed by (core/core)
forge.cloud.adibilis.ch/platform/ci-images:maven25-node24	maven-node.Dockerfile	backend-test, publish-api-types jobs
forge.cloud.adibilis.ch/platform/ci-images:playwright-1.63.0	playwright-docker.Dockerfile	the three e2e shard jobs

Reference a tag directly in a job's container: (or services:) config, e.g.:

container: forge.cloud.adibilis.ch/platform/ci-images:maven25-node24

Why public

This org's stated purpose is "public, secret-free infrastructure images only". Both images contain nothing but installed tooling, so they're published without access control. That means:

• consumers need no credentials: block on the container:/services: entry — no pull secret to provision or rotate;
• downstream forks of core/core reference this one shared image instead of each building a byte-identical copy into their own package namespace.

Playwright version pinning

The Playwright version baked into a playwright-<version> tag must equal the @playwright/test version in the consuming repo's lockfile. If either side moves without the other, Playwright downloads a second browser set at runtime — silently undoing the point of pre-baking it into the image. So a consumer's upgrade runs in this order: add the new tag here, let it publish, then bump the consumer's lockfile and its container: in the same commit.

That means two tags coexist for the length of an upgrade, which is why the version is a PLAYWRIGHT_VERSION build arg and the workflow matrix carries one entry per tag — one Dockerfile, no copy to drift. Delete an entry once nothing references its tag (git grep playwright- in the consumers); the published package keeps the tag either way, it just stops being rebuilt. playwright-1.58.2 was dropped that way on 2026-09-26, once core/core's e2e jobs had moved to 1.63.0.

The smoke test asserts the baked version by reading the base image's own /ms-playwright/.docker-info. Do not use npx playwright --version for this: with no local install it downloads that version from npm first and then reports what it just fetched, so it passes whatever the image actually contains.

Toolchain versions

maven25-node24 pins both halves of its name, and the build asserts them:

• JDK 25 — the LTS, and the same major as the backend's runtime image (eclipse-temurin:25-jre), so build and runtime stay aligned. Lombok, MapStruct and QueryDSL all run through javac internals during the build; they are what a JDK bump breaks first, so the backend test suite is the real gate on changing this.
• Node 24.21.0 — copied from the official node:24.21.0-alpine image rather than installed with apk add nodejs, which serves Alpine's LTS line (Node 22.23.2 on 3.21 and 3.22) and pins nothing.

Neither may be bumped here alone: change the consuming repo first, or together.

Rebuilding

The .forgejo/workflows/build.yml workflow rebuilds and republishes both tags. It runs on:

• a push to main touching either *.Dockerfile or the workflow file itself;
• a manual workflow_dispatch run.

Each image is smoke-tested (build succeeds, expected binaries run) before it is pushed, so a broken image is never published.

Publishing

The build workflow pushes with a REGISTRY_TOKEN repo secret, not the job token: this instance answers the job token with unauthorized: reqPackageAccess on a package push. The secret needs package read+write on the platform org. Pulling stays anonymous — the registry hands out unauthenticated pull tokens for this package, which is why consumers need no credentials.