apk not found
Closed this issue · 3 comments
Synopsis
When using FROM adminer:4.8.1 in a Dockerfile and running apk, docker build reports:
/bin/sh: 1: apk: not found
Note: On September 30, 2022, the issue didn't exist. So to the best of my knowledge it's due to a change between October 2022 and April 2022. Perhaps https://github.com/TimWolla/docker-adminer/pull/129/files
Details
The error can currently be seen at https://github.com/Senzing/docker-adminer/actions/runs/4883148233/jobs/8714101185?pr=22
Step 6/10 : RUN apk add --no-cache --virtual .php-ext-deps freetds unixodbc && apk add --no-cache --virtual .build-deps freetds-dev unixodbc-dev && docker-php-ext-configure pdo_odbc --with-pdo-odbc=unixODBC,/usr && docker-php-ext-install pdo_odbc pdo_dblib && apk del .build-deps && rm -rf /var/cache/apk/*
---> Running in 43e81a891f9b
/bin/sh: 1: apk: not foundThe repository that exposes the issue is https://github.com/Senzing/docker-adminer. In the Pull Request history, https://github.com/Senzing/docker-adminer/pulls?q=is%3Apr, there's a successful build dated September 30, 2022 and an unsuccessful Pull Request 21
In the future, might it be possible to keep versioned docker image stable? Such as adminer:4.8.1 being the pre- #129 version and perhaps a adminer:4.8.2 being a post- #129 version. That way your customers can pin their Docker images to an unchanged image.
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.
Independent of the understanding of the word "customer", the thought is that a user of your code whether doing
docker pull adminer:4.8.1or
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
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