6 Commits

Include renames

Author	SHA1	Message	Date
timothy	32747a067e	docs(445): note the ci-image-pin length guard in the rebase-trap warning ... Second pin-recovery cycle on this branch — main moved twice during review and each rebase rewrites the sha of the commit that touched docker/ci. Records that #598 now length-checks the pin at exactly 7 chars, which turns a locally-computed 8-char `git rev-parse --short` into a loud gate failure instead of a confusing manifest-unknown at image-pull time. That guard came from #594, filed by this session after hitting exactly that ambiguity. This commit also IS the recovery: it touches docker/ci, so ci-image.yml tags it and the pin can be re-pointed in the follow-up commit. Refs #445 #594	2026-07-25 14:29:27 +02:00
timothy	5dd0b147e8	docs(445): record that rebasing invalidates the CI toolchain image pin ... Hit this for real on this branch. `ci-image-pin` went red after a rebase that was otherwise clean, and the failure is confusing on three counts: - the pin must equal the short sha of the commit that touched docker/ci, and a rebase REWRITES that sha (e9fd26f6 -> 9130274c here); - the pin still resolves to a real commit and the tagged image still exists in the registry, so nothing looks broken; - the force-push does NOT republish: ci-image.yml filters on `paths: docker/ci/**`, and a rebase that leaves the Dockerfile's content unchanged produces no diff for that path. And it cannot be fixed by re-dispatching ci-image.yml, because that tags `git rev-parse --short HEAD` — the branch HEAD, not the commit that touched docker/ci. The two coincide only when the docker/ci commit IS HEAD, which is why the original two-step worked and the post-rebase state does not. Recorded in docs/ci-cd.md with the recovery, plus the cheaper lesson: land a toolchain-image change on its OWN branch first, so the consuming branch never carries the docker/ci commit through a rebase. This commit is also the recovery itself — it touches docker/ci, so it becomes the commit ci-image.yml tags, restoring the pin dance. Refs #445	2026-07-25 14:04:52 +02:00
timothy	cb5d1af65f	ci(445): bake headless Chromium into the CI toolchain image ... Adds `chromium-headless-shell` + its system deps to the shared CI toolchain image so the `functional-e2e` job can run the UI-E2E Playwright flows without installing a browser per run — the same "jobs install nothing at run time" rule as the rest of this image. Measured on this exact base (Ubuntu 24.04 ffmpeg base, amd64): - headless shell: 267M vs full chromium: 656M - `chromium.launch()` resolves to the shell anyway (the config never asks for headed), so the only cost is that a HEADED run inside this image would fail — CI-only, and deliberate. - Chromium launches as root in a container with NO --no-sandbox / chromiumSandbox:false opt-out, so the Playwright config needs no sandbox workaround. Verified rather than assumed. `ARG PLAYWRIGHT_VERSION` must stay equal to web/package.json's EXACT `@playwright/test` pin: Playwright ties a browser revision to the package version, so a mismatch leaves no usable browser. The build-time smoke test LAUNCHES the browser (not just a file test), so a missing system library fails the image build instead of a CI run. First half of the deliberate two-step toolchain bump: this commit is what ci-image.yml publishes as :<sha>; the follow-up commit pins it. Refs #445	2026-07-25 14:02:31 +02:00
timothy	07048b8c96	ci(390): address cold review — pin-drift guard, honest cron, doc fixes ... Cold adversarial review findings: - MEDIUM (Renovate generates pin drift): add a blocking ci-image-pin job. Renovate manages docker/ci/Dockerfile's base pins but cannot bump an opaque :<sha> in container.image, so a base bump would publish a new image, test the OLD one, and merge with the Dockerfile disagreeing with the pin. The guard fails when the pin isn't the last commit to touch docker/ci, or when the 5 jobs pin different tags — making the documented two-step enforced rather than remembered. - MEDIUM (cron was a no-op): the weekly rebuild updated nothing (jobs pin :<sha>) and buildcache would have restored the apt layer verbatim, collecting none of the base updates it existed for. Added no-cache on the schedule path and rewrote the comment to state what it actually is: a build canary + a fresh :latest for the next bump. - LOW: FFMPEG_TAG was referenced in the Dockerfile + docs but never existed (the FROM is hardcoded); reworded both. - LOW: paths: filtered the exact file while the docs claimed docker/ci/** — use **. - NIT: docs oversold ENTRYPOINT reset as a gotcha; act overrides it anyway. Marked defensive. Refs #390	2026-07-17 09:34:46 +02:00
timothy	6a9e27c6b8	ci(390): fix CI-image smoke test — reportgenerator --version exits 1 ... The build-time smoke test failed the image build even though the toolchain was healthy: reportgenerator prints its version banner then exits 1 ("No report files specified"), so it has no clean version probe. Probe the dotnet-tool shim on PATH instead. dotnet --info confirmed the SDK + .NET 10.0.10 runtimes resolve correctly on the ffmpeg base (ICU/glibc fine). Refs #390	2026-07-17 09:13:09 +02:00
timothy	f27ff876d0	ci(390): add shared CI toolchain image (.NET 10 SDK + Node 22 + prod ffmpeg) ... Layers the .NET 10 SDK + Node 22 onto our own ersatztv-ffmpeg base (the same COPY --from=.../usr/share/dotnet pattern docker/Dockerfile uses for prod), and bakes the dotnet-ef + reportgenerator global tools the jobs installed per run. Builds/pushes 192.168.1.95:3000/timothy/ersatztv-ci:<sha> via a separate workflow so a ~2GB toolchain image isn't rebuilt on every commit. Refs #390	2026-07-17 09:09:11 +02:00