ci: notice when a new Debian stable leaves the pinned suite behind - #733
Merged
Conversation
Go never resolves ".local" itself. net/conf.go routes those names to libc only when cgo is available, and every FTW build sets CGO_ENABLED=0, so the pure Go resolver is always selected: a configured "zap.local" became a unicast DNS query to the site router and failed. That holds on every base image and every libc, musl and glibc alike, so the container's distro was never the variable here. Add internal/mdnsresolve, which answers those names over multicast DNS, and route every driver transport through it: Modbus TCP, MQTT (driver and Home Assistant bridge), HTTP including the TLS-pinned client, WebSocket and raw TCP. Only ".local" names take the new path; literal IPs and ordinary DNS names dial exactly as before. Resolution runs per dial rather than once at startup, so a device that moves to a new DHCP lease is found again on the next reconnect with no config edit. Answers are cached for the record TTL clamped to 30-120s so reconnect loops cannot flood the LAN, and failures are cached for 5s so a still-booting device is retried soon. Failures log "mDNS resolution failed" and name the mechanism rather than surfacing as a generic dial error. The scanner's reverse PTR lookup moves into the same package so there is one mDNS implementation instead of two. Co-authored-by: HuggeK <48095810+HuggeK@users.noreply.github.com>
Core was alpine:3.22 and the updater sidecar was docker:27-cli (also alpine), while the optimizer was already python:3.12-slim-bookworm. That is two libcs and two security streams in one deployment, and two base rootfs blobs pulled per host. Put all three on debian:bookworm-slim so the layer is pulled once and tracked once. glibc additionally lets the image run ordinary prebuilt vendor binaries, which musl cannot, and a full userland makes on-site docker exec debugging practical. libnss-mdns is installed and wired into nsswitch.conf so .local resolves for glibc tools inside the container when an avahi socket is mounted; the FTW process does not depend on that, because a CGO_ENABLED=0 binary bypasses NSS entirely and resolves .local in Go instead. The binary stays fully static and still cross-compiles on the build platform, so only the small runtime layer is emulated for arm64. Measured: 79s for a full arm64 build, image 148MB (amd64 128MB, up from 53MB). wget is now installed explicitly and asserted by the boundary test. It is contractual rather than incidental: ftw-updater docker-execs it inside the core image to decide whether an update commits, and updaters already in the field will keep doing so, so the core image cannot stop shipping it. The boundary test's `^FROM alpine:` line is replaced by the invariant it was actually standing in for -- core must not build on a Python base -- and given a real error message. Also embed tzdata in the binary as a fallback. Production code reads time.Local, which silently degrades to UTC when zoneinfo is missing, and the tzdata tests skip rather than fail, so that regression would ship green. Verified uid 100 / gid 101 have no passwd entry on this base, and corrected the two comments that attributed them to an alpine adduser. Co-authored-by: HuggeK <48095810+HuggeK@users.noreply.github.com>
bookworm is oldstable. Move all three images to trixie so the deployment tracks the suite that is actually receiving full security support, and so the base matches the Raspberry Pi OS release the SD image is built from (deploy/pi-gen/config: RELEASE=trixie). This also brings the optimizer along. Leaving it on a bookworm-derived python image would have split the shared base layer, which is the whole reason the images were aligned -- verified after the move that core, updater and optimizer resolve to one identical base layer digest. Verified on trixie: CVXPY 1.9.2 solves and highspy imports under Python 3.12.13; the updater's copied docker CLI 27.5.1 and compose plugin v2.33.0 both run; core has wget, the CA bundle, zoneinfo and an nsswitch.conf wired for mdns, and runs as uid 100 / gid 101. Pinned to the codename rather than a stable alias, so a major-version jump can never arrive silently on a rebuild. Co-authored-by: HuggeK <48095810+HuggeK@users.noreply.github.com>
The images pin a Debian codename rather than a suite alias, so a major version jump can never arrive silently on a rebuild. The cost of pinning is that nothing notices when a new stable ships, and a suite quietly stops receiving full security support once it becomes oldstable -- which is exactly the state bookworm was already in. Truth comes from Debian's own Release file for the stable suite, not from registry tag listings: tags are noisy, rate-limited, and say nothing about which suite Debian considers stable. The check reads the pin out of the three Dockerfiles rather than hard- coding it, so it cannot drift from what actually ships, and it fails the run rather than reporting "current" if it could not reach Debian. It also flags the images having drifted apart, since a split pin silently costs the shared base layer they were aligned for. When a new stable is found it reports whether debian:<suite>-slim and the matching python:<ver>-slim-<suite> are actually published yet, because the python image can lag by days and moving core alone would split the pin. Follows the bundled-driver-pin workflow: one issue, rewritten each run and closed automatically once the pin is current, so a suite left alone for a year costs one thread rather than fifty-two. Co-authored-by: HuggeK <48095810+HuggeK@users.noreply.github.com>
This was referenced Jul 31, 2026
The optimizer releases independently of core, and optimizer-release.yml skips the build entirely when an image already exists for the requested version, then asserts that the published image's org.opencontainers.image.revision label matches the commit being released. Changing Dockerfile.optimizer without moving the version therefore does not merely produce two different artifacts under one number -- it cannot ship at all. Releasing 1.3.2 from this commit would either reuse the bookworm image or fail metadata verification. Minor rather than patch: the Python surface is untouched, but the runtime underneath it moves a Debian major version, so consumers are getting a materially different artifact. Co-authored-by: HuggeK <48095810+HuggeK@users.noreply.github.com>
@ The base move and the resolver were stacked in one branch, which made the resolver look like a consequence of choosing Debian. It is not: the two are independent, and the resolver is the one with the device-facing risk. Take the resolver back out so this branch is only the base move, and restate what libnss-mdns actually buys here — tools inside the image, not the FTW process, which is CGO_ENABLED=0 and never consults NSS. Co-authored-by: HuggeK <48095810+HuggeK@users.noreply.github.com> @
This was referenced Aug 4, 2026
srcfl#731 landed the base move itself, so this branch keeps only the part that was never in it: a check that notices when the pinned codename stops being what Debian calls stable. Dependabot cannot cover this. It orders numeric tags, and `trixie` is a codename with no numeric component — the same is true of the suite half of `python:3.12-slim-trixie`. It bumps the interpreter and leaves the suite alone. This reads Debian's own Release file for `stable` instead of a registry tag listing, and also fails when the three images stop agreeing on one suite, which is the whole reason they were aligned. Co-authored-by: HuggeK <48095810+HuggeK@users.noreply.github.com>
HuggeK
changed the title
HuggeK
marked this pull request as ready for review
August 5, 2026 06:20
The `no-changeset` label is the right escape hatch here, but applying a label needs write access to srcfl/ftw. A patch entry saying no runtime behaviour changes keeps the gate honest without one. Co-authored-by: HuggeK <48095810+HuggeK@users.noreply.github.com>
Co-authored-by: HuggeK <48095810+HuggeK@users.noreply.github.com>
Contributor
Author
|
Pushed ab4af74: the |
Member
|
Rechecked after updating the branch to current |
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
3 participants
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.
Now that #731 has landed, this is reduced to the one thing that was never part
of it: something that notices when the pinned Debian suite stops being Debian
stable.
Why Dependabot doesn't already do this
.github/dependabot.ymldoes watch all three Dockerfiles —package-ecosystem: dockerat/, and the updater matches an unanchored/dockerfile|containerfile/i,so
Dockerfile.optimizerandDockerfile.updaterare picked up alongsideDockerfile. It works: #788 is Dependabot proposingpython:3.12-slim-trixie→3.14-slim-trixieright now.What it moved there is the interpreter, not the suite. Dependabot orders
tags that carry a version it can compare, and
trixieis a codename with nonumeric component:
debian:trixie-slimtrixie→forkypython:3.12-slim-trixie3.12→3.14trixie→forkySo a new Debian stable can ship and every Dependabot run stays silent, while the
three images quietly sit on oldstable.
Why not just switch to a tag Dependabot can order
debian:13-slimexists (so does13.6-slim), so core and the updater could bepinned numerically and Dependabot would eventually offer
14-slim.The optimizer has no equivalent. Docker Hub's
pythonimages express the suiteonly as a codename —
3.12-slim-trixie,3.12-slim-bookworm,3.12-slim-bullseye.The one alternative, bare
3.12-slim, floats the suite silently, which is theopposite of what we want. So a numeric pin would cover two images out of three
and leave the pins in two different styles, which is exactly what the
three-way agreement check below exists to catch.
debian:stable-slimwould track stable by definition and is worse for the samereason it was rejected originally: a major-version jump would arrive on an
ordinary rebuild with nothing to review.
What this adds
scripts/check-debian-base.sh, plus a weekly workflow that runs it and opensnothing — it just fails, visibly.
from what ships.
dists/stable/Releasefile, not a registry taglisting — tags are noisy, rate-limited, and say nothing about which suite
Debian considers stable.
single base layer is why they were aligned in build: run one base across the whole stack (debian:trixie-slim) #731, and that benefit is gone
the moment they diverge.
scripts/sync-bundled-drivers.sh --behind:0current,1behind or disagreeing,
2could not run — a network failure is never reportedas "fine".
Verified
Run against current master:
make compose-migration-testnow includes it in thebash -nsweep.A
patchchangeset is included stating that no runtime behaviour changes. Theno-changesetlabel would be the better fit — applying one needs write accessto this repo, so swap it in and drop the entry if you prefer.