[antoinetoussaint-byte]

What broke

Since 2026-10-26 every PR (#194, #195, #196) has failed image at "Verify runtime image candidate". All three built the same digest, sha256:e9b799a7…, against the locked sha256:20295012…, and ci was skipped. None of them touches the Dockerfile.

Root cause

The two indexes differ in exactly one layer per platform: the runtime stage's apk add --no-cache --upgrade layer. The pgvector COPY layer and every base layer are byte-identical, so the builder stage and build-base are not the cause. Inside that layer the only difference in lib/apk/db/installed is:

- musl=1.2.6-r2
+ musl=1.2.6-r3

The new layer also carries lib/ld-musl-*.so.1. apk add --upgrade upgrades the dependencies of every package it names. libcrypto3, libssl3, libuuid and su-exec all depend on musl, and musl was not named, so it floated with the Alpine v3.24 index. When Alpine published musl 1.2.6-r3, it replaced the base image's 1.2.6-r2. apk add --simulate against the pinned base confirms that musl is the only unnamed package the transaction changes.

Fix

• Every package this apk add changes is now named at an exact version: musl=1.2.6-r3 joins libcrypto3, libssl3, libuuid and su-exec. If Alpine rebuilds musl again, the build fails with "unable to select packages" instead of drifting silently. This is the same failure mode the other pins already have.
• TestRuntimeDockerfilePinsReproducibleBuildInputs asserts the new pin.
• The runtime-image-relock skill now says to pin the whole transaction and shows how to list it (apk add --simulate).
• runtime-image.json is re-locked through the skill's loop: CI publishes the candidate by digest, then the lock takes the built digest. The tag string does not change (postgres 17.10, pgvector 0.8.5, alpine 3.24).

Classification: fix, at the place that owns the behaviour (the runtime image's package pins). It is not a digest bump: the input that moved is now pinned. Reused: the repo's existing pin test, its relock loop and CI's own reproducible build flags. No new mechanism.

Evidence

• Built locally with CI's exact buildkit (moby/buildkit@sha256:2f5adac4…, docker-container driver), using the same flags as the candidate publish (SOURCE_DATE_EPOCH=0, rewrite-timestamp=true, no provenance or SBOM, linux/amd64+arm64):
  • main unchanged gives sha256:e9b799a7…, exactly what CI built on feat(runtime): share local Postgres through a server dependency #194–feat(runtime): one native Postgres server per run, a database and an owner per service #196. The local method reproduces CI.
  • This branch, two separate --no-cache builds, gives sha256:1d7680adb926a17a378b4f56e4b33ed98b64c8dabf39f2301b6d5d71ff5c75e3 both times.
• Unit suite (CI's skip list) green locally with docker.

Not verified / remaining risk

• The pgvector builder stage still installs about 45 unpinned transitive packages under build-base/clang21/llvm21-dev (gcc, binutils, musl-dev, …). They also moved on 2026-10-26, and the .so came out byte-identical, so they did not cause this break. Their output is still not pinned, though. If a toolchain rebuild ever changes the pgvector bytes, this same check will catch it.
• I did not push a candidate from my machine. CI's publish is the one that lands in ghcr.

🤖 Generated with Claude Code