search

TimWolla / docker-adminer

Database management in a single PHP file
https://hub.docker.com/_/adminer/
157 stars 69 forks source link

apk not found #143

Closed docktermj closed 1 year ago

docktermj commented 1 year ago

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 found

The 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.

TimWolla commented 1 year ago

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.

docktermj commented 1 year ago

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

TimWolla commented 1 year ago

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