docker: refresh the debian:bookworm-slim digest for the scanners stage - #104
Merged
Merged
Conversation
Rolls the pinned digest for the scanner-download stage forward to the current debian:bookworm-slim (verified against the registry: the tag resolves to 7b140f37... today). That stage curls and checksum-verifies the trivy/grype/syft binaries, so its curl and CA bundle should not drift; none of its layers ship in the runtime image. Split out of the grouped Dependabot docker-images bump, whose other half (node 22 -> 26 for the frontend builder) is a major on a non-LTS Node line and is evaluated separately.
tyler-rich
added a commit
that referenced
this pull request
Jul 26, 2026
… Node 24 and frontend-tooling work (#107) Rolls the frontend-builder base digest forward to the current node:22-bookworm-slim. Verified against the registry rather than taken from bump metadata: registry-1.docker.io resolves the 22-bookworm-slim tag to 6c74791e..., that index carries both linux/amd64 and linux/arm64, and Docker Hub's tag listing shows the same digest on 22.23.1-bookworm-slim and jod-bookworm-slim, which is what establishes the version behind the moving tag. No stage boundary, layer ordering, or cache scope changed. Same case as the debian refresh in #104: Dependabot's docker-images group offers node 22 -> 26, a major on a line that is not LTS, not a digest refresh within 22, so declining the major left the pin stale. Node 22 is supported through 2027-04-30; 24 (Active LTS, through 2028-04-30) is the target and 26 is not LTS until 2026-10-28. Also records three items that had been decided but written down nowhere a reader would find them, in docs/ROADMAP.md near-term: the Node 22 -> 24 move (Dockerfile + ci.yml + CONTRIBUTING together), the frontend tooling majors left over from Dependabot #86 after the Mantine/React ignores (TypeScript 5.7 -> 7.0, ESLint 9 -> 10, typescript-eslint 8.65, Vite 6 -> 8, Vitest 3 -> 4, jsdom 26 -> 29, all landing on the type-aware ESLint gate), and the deprecated Starlette HTTP_422_UNPROCESSABLE_ENTITY / HTTP_413_REQUEST_ENTITY_ TOO_LARGE constants at 22 and 2 call sites. See docs/ARCHIVE.md section 14 for the dated entry.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The mergeable half of Dependabot #92. That PR groups two unrelated changes; this takes only the base-image digest refresh. The other half —
node22 → 26 on the frontend builder — is a major on a non-LTS Node line and is evaluated separately (see below). #92 can be closed once this lands.What changed
docker/Dockerfile, one line:Verified against the registry rather than taken from the bump description:
debian:bookworm-slimresolves tosha256:7b140f374b289a7c2befc338f42ebe6441b7ea838a042bbd5acbfca6ec875818today, which is exactly the proposed digest.Why it matters (and what it doesn't do)
One correction to how this bump is easy to describe: it does not feed the dogfood scan gate. The
scannersstage is a build stage — the runtime image ispython:3.14-slim-bookworm, and only three files (trivy,grype,syft) are copied out ofscannersinto it. Nothing from the Debian layer ships, so Trivy/Grype never see it.What the refresh is actually worth is build-stage hygiene: that stage
curls the scanner release tarballs and checksum-verifies them, so itscurland its CA bundle are on the path that decides whether the right binaries get into the image. Letting them drift is the thing to avoid.While checking this, the runtime base was verified too:
python:3.14-slim-bookwormstill resolves to the pinnedsha256:86f975ac…, so the image that does feed the gate is already current and needs no change here.Note: the
node22 pin is stale independently of the major bumpnode:22-bookworm-slimnow resolves tosha256:6c74791e…, but the Dockerfile pinssha256:53ada149…. Dependabot offered 26 instead of a 22 digest refresh, so declining the major leaves the builder on an old 22. Not folded in here to keep this PR to the one line it claims — flagged for a follow-up.Verification
docs/ARCHIVE.md§ Build performance).