The runtime stage of the Dockerfile now uses alpine:3.22, pinned by digest, instead of alpine:3.21. The test phase and the build stage use the golang image built on Alpine 3.22, so pixad was compiled against libvips 8.16 and ran against libvips 8.15. All three stages now take their packages from the same Alpine release. Closes #229.
The golang pins are now written golang:1.25.4-alpine3.22, with the same digest as before, and their comments say that the runtime stage uses Alpine 3.22 too, so whoever bumps the golang image sees which release the runtime stage has to match. A comment on the runtime FROM line says the same from its side.
The runtime packages (vips, vips-jxl, libheif, ca-certificates, tzdata, su-exec) have the same names in 3.22. README.md said the image has libvips 8.15 and now says 8.16.
Not visible in the diff: the two base images are different patch releases of 3.22 (the golang image is 3.22.2, the new runtime image 3.22.6). That does not matter for libvips: every stage installs it with apk add from the same 3.22 package repository when the image is built, so all of them get the same version.
Not checked: JPEG XL output from pixad in the image, as JPEG XL is not a format on next yet.
Model: opus-5-5
The runtime stage of the `Dockerfile` now uses `alpine:3.22`, pinned by digest, instead of `alpine:3.21`. The test phase and the build stage use the golang image built on Alpine 3.22, so pixad was compiled against libvips 8.16 and ran against libvips 8.15. All three stages now take their packages from the same Alpine release. Closes https://git.eeqj.de/sneak/pixa/issues/229.
The golang pins are now written `golang:1.25.4-alpine3.22`, with the same digest as before, and their comments say that the runtime stage uses Alpine 3.22 too, so whoever bumps the golang image sees which release the runtime stage has to match. A comment on the runtime `FROM` line says the same from its side.
The runtime packages (`vips`, `vips-jxl`, `libheif`, `ca-certificates`, `tzdata`, `su-exec`) have the same names in 3.22. `README.md` said the image has libvips 8.15 and now says 8.16.
Not visible in the diff: the two base images are different patch releases of 3.22 (the golang image is 3.22.2, the new runtime image 3.22.6). That does not matter for libvips: every stage installs it with `apk add` from the same 3.22 package repository when the image is built, so all of them get the same version.
Not checked: JPEG XL output from pixad in the image, as JPEG XL is not a format on `next` yet.
Model: opus-5-5
Dockerfile:80-82: the new comment says the runtime stage must use the Alpine release the golang image is based on, but the golang pins' comments (Dockerfile:20 and Dockerfile:43, golang:1.25.4-alpine) name no Alpine release. A reader cannot see which release that is, and whoever bumps the golang image, which is how the two stages drifted apart, gets no reminder on the lines they change. Acceptable: name the release in those two comments as golang:1.25.4-alpine3.22 (the same digest, sha256:d3f0cf77…), and say there in a few words that the runtime stage uses the same release, so all three pins say 3.22.
TODO.md:35-36: "so all three have libvips 8.16 instead of 8.15 in the runtime image" puts all three stages "in the runtime image". Acceptable: "so all three have libvips 8.16, where the runtime image had 8.15."
Model: opus-5-5
1. `Dockerfile:80-82`: the new comment says the runtime stage must use the Alpine release the golang image is based on, but the golang pins' comments (`Dockerfile:20` and `Dockerfile:43`, `golang:1.25.4-alpine`) name no Alpine release. A reader cannot see which release that is, and whoever bumps the golang image, which is how the two stages drifted apart, gets no reminder on the lines they change. Acceptable: name the release in those two comments as `golang:1.25.4-alpine3.22` (the same digest, `sha256:d3f0cf77…`), and say there in a few words that the runtime stage uses the same release, so all three pins say 3.22.
2. `TODO.md:35-36`: "so all three have libvips 8.16 instead of 8.15 in the runtime image" puts all three stages "in the runtime image". Acceptable: "so all three have libvips 8.16, where the runtime image had 8.15."
Model: opus-5-5
The runtime stage of the Dockerfile moves from alpine:3.21 to
alpine:3.22, pinned by digest. The test phase and the build stage use
the golang image built on Alpine 3.22, so pixad was compiled against
libvips 8.16 and ran against 8.15. All three stages now install their
packages from the same Alpine release, where the runtime packages keep
their names. The golang pins now name that release as
golang:1.25.4-alpine3.22, with the same digest, and say that the runtime
stage uses it too. README.md now says the image has libvips 8.16.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The runtime stage of the
Dockerfilenow usesalpine:3.22, pinned by digest, instead ofalpine:3.21. The test phase and the build stage use the golang image built on Alpine 3.22, so pixad was compiled against libvips 8.16 and ran against libvips 8.15. All three stages now take their packages from the same Alpine release. Closes #229.The golang pins are now written
golang:1.25.4-alpine3.22, with the same digest as before, and their comments say that the runtime stage uses Alpine 3.22 too, so whoever bumps the golang image sees which release the runtime stage has to match. A comment on the runtimeFROMline says the same from its side.The runtime packages (
vips,vips-jxl,libheif,ca-certificates,tzdata,su-exec) have the same names in 3.22.README.mdsaid the image has libvips 8.15 and now says 8.16.Not visible in the diff: the two base images are different patch releases of 3.22 (the golang image is 3.22.2, the new runtime image 3.22.6). That does not matter for libvips: every stage installs it with
apk addfrom the same 3.22 package repository when the image is built, so all of them get the same version.Not checked: JPEG XL output from pixad in the image, as JPEG XL is not a format on
nextyet.Model: opus-5-5
Dockerfile:80-82: the new comment says the runtime stage must use the Alpine release the golang image is based on, but the golang pins' comments (Dockerfile:20andDockerfile:43,golang:1.25.4-alpine) name no Alpine release. A reader cannot see which release that is, and whoever bumps the golang image, which is how the two stages drifted apart, gets no reminder on the lines they change. Acceptable: name the release in those two comments asgolang:1.25.4-alpine3.22(the same digest,sha256:d3f0cf77…), and say there in a few words that the runtime stage uses the same release, so all three pins say 3.22.TODO.md:35-36: "so all three have libvips 8.16 instead of 8.15 in the runtime image" puts all three stages "in the runtime image". Acceptable: "so all three have libvips 8.16, where the runtime image had 8.15."Model: opus-5-5
347ac7c954to2ac56a3e43Review passed.
Model: opus-5-5