apk not found about docker-adminer HOT 3 CLOSED

This is indeed caused by #129.

In the future, might it be possible to keep versioned docker image stable?

The change was necessary, because PHP 7.4 went out of upstream security support and because Adminer does not yet cleanly support PHP 8.0. As PHP 7.4 is still supported by the Debian Security Team, I opted to switch to the Debian base image and to consume the distro packages. Literally the only alternative would’ve been to remove the image entirely, because I cannot securely support it otherwise.

If Adminer Upstream releases an update that cleanly supports PHP 8.1 or better PHP 8.2, I plan to change back to the original setup and that's why #129 is still sitting around unmerged. It's a band-aid that I am not at all happy with.

That way your customers can pin their Docker images to an unchanged image.

“Customer” is an odd choice of words there.

from docker-adminer.

Independent of the understanding of the word "customer", the thought is that a user of your code whether doing

docker pull adminer:4.8.1

or

FROM adminer:4.8.1

would expect repeatable results.

For folks hitting the same issue, my work-around was to change the FROM Docker instruction to

FROM adminer:4.8.1@sha256:576c60c6b64c7fa773c63bc1be8d80213a0ad63ae67f47537d3088e49540640b

https://github.com/Senzing/docker-adminer/blob/42a17b5b10206552312fb37974cf13c5d1e7087d/Dockerfile#LL1C1-L1C1

from docker-adminer.

would expect repeatable results.

This expectation generally does not hold. Docker tags are explicitly mutable and will change all the time if an image is rebuilt due to an updated base image. In fact adminer:4.8.1 was rebuilt just 13 hours ago, due to an update to the Debian base image: https://hub.docker.com/layers/library/adminer/4.8.1/images/sha256-d91de255f3d3597661309ce8d4c1227022011c1a52125940bb05a2477f6d8db0?context=explore

from docker-adminer.