v1.1.0 never published: released images have no pdo_sqlsrv/sqlsrv despite the README

[qisthidev]

The v1.1.0 publish workflow failed, so no published image contains pdo_sqlsrv / sqlsrv even though the README lists them under "Included PHP Extensions". Every rolling tag (latest, php8.5-prod, php8.5-base, php8.5-frankenphp-debian) still points at the v1.0.0 build.

What is published today

Docker Hub tag listing (all v1.0.0-era, no v1.1.0 tags at all):

Tag	last_updated
latest	2026-08-05T16:47:03Z
php8.5-prod	2026-08-05T16:47:38Z
php8.5-base	2026-08-05T16:47:35Z
php8.5-frankenphp-debian	2026-08-05T16:47:32Z
php8.5-*-v1.0.0	2026-08-05T16:46:5xZ

Release v1.1.0 "MS SQL Server driver" was cut at 2026-08-05T23:31:18Z — about 7 hours after those images were pushed.

Both Docker Publish runs for that change failed:

• 31056645861 (push to main, "feat: add MS SQL Server driver") — failure
• 31056655109 (release v1.1.0) — failure

Verified in the published image

php8.5-frankenphp-debian pulls digest sha256:21f8ea636304afc1172316566c4d7795a25d84c7e0d9a3d7f7b153fdb3a5efb4, which is exactly the digest Docker Hub reports for that tag — so this is not a stale local copy.

$ docker run --rm --entrypoint sh laravoltdev/image:php8.5-frankenphp-debian -lc 'php -m'
... bcmath ... exif ... gd ... intl ... pdo_mysql pdo_pgsql pdo_sqlite ...
# no sqlsrv, no pdo_sqlsrv

$ ls /usr/local/etc/php/conf.d/
docker-php-ext-bcmath.ini  docker-php-ext-exif.ini  docker-php-ext-gd.ini
docker-php-ext-intl.ini    docker-php-ext-pcntl.ini docker-php-ext-pdo_mysql.ini
docker-php-ext-pdo_pgsql.ini docker-php-ext-redis.ini docker-php-ext-sodium.ini
docker-php-ext-zip.ini     serversideup-docker-php.ini
zzz-serversideup-docker-php-debug.ini
# no ini for sqlsrv / pdo_sqlsrv either

bcmath, exif, gd, intl are all present — only the two SQL Server drivers are missing, which lines up exactly with the failed release.

Why the build failed

From run 31056655109:

#9 1236.8    1. msodbcsql17:amd64=17.11.1.1-1 is selected for install
#9 1236.8    2. msodbcsql17:amd64 Depends libc6:amd64 (>= 2.19)
#9 1236.8       but none of the choices are installable:
#9 1236.8       [no choices]

#9 ERROR: process "/bin/sh -c install-php-extensions bcmath exif gd intl pdo_sqlsrv sqlsrv"
          did not complete successfully: exit code: 100

install-php-extensions pulls msodbcsql17, and apt cannot satisfy its libc6 dependency on the Debian suite used by serversideup/php:8.5-frankenphp-debian-v4.5.1. Microsoft only publishes msodbcsql18 for the newer Debian releases, so pinning to 18 (and passing ACCEPT_EULA=Y) is usually what fixes this. Worth checking which Debian suite the MS repo is being configured for inside that base.

Impact for consumers

Anyone following the README and deploying a Laravolt app against SQL Server gets a runtime failure (could not find driver) instead of a build-time one, because the image builds fine — it just silently lacks the drivers. We hit this while auditing our CI image; our own app runs on SQL Server.

Suggestions

1. Fix the extension install, re-cut the release, and confirm latest / php8.5-* actually move.
2. Until then, consider a note in the README so the extension table matches what is published.
3. Optional: make the publish workflow's failure louder — a green README next to two red workflow runs is easy to miss.

Unrelated small DX note

When extending the image (FROM laravoltdev/image:php8.5-frankenphp-debian), the default user is www-data, so the first RUN that writes outside the app directory fails:

ln: failed to create symbolic link '/usr/local/bin/bun': Permission denied

That default is correct for a runtime image and src/Dockerfile already does USER root internally — it just isn't obvious to someone deriving from it. One line in the README ("switch to USER root before installing, then drop back") would save the next person a build cycle.