IBX-12474: Moved Docker images off end-of-life Debian 11 - #68
Merged
Conversation
KamilSznajdrowicz
approved these changes
Sep 8, 2026
alongosz
requested review from
Steveb-p,
ViniTou,
barbaragr,
barw4,
bnowak,
ciastektk,
juskora,
katarzynazawada,
konradoboza,
micszo,
mikadamczyk,
pawlakadrian,
tbialcz,
tomaszszopinski and
wiewiurdp
September 8, 2026 11:41
konradoboza
approved these changes
Sep 8, 2026
micszo
approved these changes
Sep 8, 2026
bnowak
approved these changes
Sep 8, 2026
ViniTou
approved these changes
Sep 8, 2026
mikadamczyk
approved these changes
Sep 8, 2026
tbialcz
approved these changes
Sep 8, 2026
Debian 11 (bullseye) reached end of LTS on 2026-08-31. Its packages are being removed from deb.debian.org while the indexes still advertise them, so apt-get install fails with sporadic 404s. php:8.1-8.4-fpm-bookworm exist, so these images can simply move to Debian 12. libicu67 is bullseye-only and becomes libicu72; every other package in the list keeps its name. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Same bullseye end-of-LTS breakage as the bookworm move, but there are no php:7.3, 7.4 or 8.0 bookworm variants, so these three have to stay on Debian 11. Point apt at snapshot.debian.org, taken a few days before the EOL, and disable the Valid-Until check that the snapshot Release files no longer pass. The official PHP images ship these very lines commented out in /etc/apt/sources.list. archive.debian.org would be the nicer target, but it only carries bullseye main so far - bullseye-security is not there yet. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
varnish:7.1 is bullseye based, so it broke the same way. varnish:7.4 is the first 7.x tag built on bookworm. varnish-modules releases map 1:1 onto Varnish minors, so bumping the base image alone is not enough - 0.20.0 fails to compile against 7.4 in vmod_header. 0.23.0 is the matching release. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
SonarCloud flagged the snapshot sources as clear-text (docker:S5332). ca-certificates ships in the php base images already, so apt can reach snapshot.debian.org over https without an extra bootstrap step. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
SonarCloud docker:S7031. Rewriting sources.list is only meaningful for the apt-get that follows it, so the two belong in one instruction. RUN count per file is now the same as before the snapshot pin was added. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The Test image step passed no credentials, so Composer inside the
container reached github.com anonymously and failed whenever the shared
runner IP was rate limited:
In AuthHelper.php line 152:
Could not authenticate against github.com
Generates an App token and forwards it as COMPOSER_AUTH into the
container, since that is where composer actually runs - a host-side
composer config would not reach it.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
alongosz
force-pushed
the
ibx-12474-debian-bullseye-eol
branch
from
September 8, 2026 13:00
c390c5e to
6c1f3e0
Compare
Debian 11 (bullseye) reached end of LTS on 2026-08-31, and its archive is
now being decommissioned. `deb.debian.org` and `security.debian.org` still
publish the bullseye package indexes, but individual `.deb` files are already
disappearing from the pools, so `apt-get install` fails with a 404 mid-build:
E: Failed to fetch .../g/gnupg2/gpgsm_2.2.27-2+deb11u3_amd64.deb 404 Not Found
E: Failed to fetch .../g/gnupg2/gnupg_2.2.27-2+deb11u3_all.deb 404 Not Found
Unable to install GPG! ... Repository installation aborted.
This breaks the `varnish` leg of Browser tests in every product repository
that uses `doc/docker/varnish.yml`. The 404s come and go depending on which
Fastly node the runner hits, so re-running the job is a lottery rather than
a fix.
Varnish 6.0 LTS is unchanged - `varnish`/`varnish-dev` 6.0.12 are published
for bookworm as well, so only the base OS moves here.
Verified locally (`docker build --platform linux/amd64`):
- the packagecloud script installs GPG and the Varnish repo without 404s
- all build dependencies resolve on bookworm
- `varnish-modules` 0.15.0 still compiles, `libvmod_xkey.so` is installed
- resulting image reports Debian 12 with `varnish 6.0.12-1~bookworm`
The same change is needed on 5.0 and 6.0, where the file is identical.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Caution
ibx-11778-gha-workflows-updateand needs retargeting to4.6before mergeRelated PRs:
Description:
Debian 11 (bullseye) reached end of LTS on 2026-08-31. Its packages are being removed from
deb.debian.orgwhile the indexes still advertise them, soapt-get installfails with a 404 on a random subset. Which packages fail depends on the Fastly node the runner hits, so re-running a job is a lottery, not a fix.That's what turns all 8
build-and-publishlegs red. It happens inside the container, so it has nothing to do with theubuntu-26.04runner change in #66.php/Dockerfile-8.1…8.4tophp:X-fpm-bookworm(libicu67->libicu72)snapshot.debian.org(20260828T000000Z) inphp/Dockerfile-7.3,7.4and8.0docker/Dockerfile-varnish7tovarnish:7.4(bookworm) with varnish-modules0.23.0docker/Dockerfile-varnishtodebian:bookworm-slim(varnish=6.0.12-1~bookworm) — cherry-picked from IBX-12474: Moved Varnish image to Debian 12 (bookworm) #67Test imagestep with an App token — unrelated to Debian, see the note belowThere are no bookworm variants of
php:7.3,7.4and8.0, so those three have to stay on bullseye. The snapshot pin is what the official PHP images ship commented out in/etc/apt/sources.listthemselves, so it's not a new trick.archive.debian.orgwould be nicer, but it only carries bullseye main —bullseye-securityisn't there yet. Worth switching once it lands.varnish-modules has to match the Varnish minor 1:1 (releases), so bumping the base image alone isn't enough. 0.20.0 doesn't compile against 7.4.
docker/Dockerfile-varnishis cherry-picked from #67 (authored by@KamilSznajdrowicz), which is now closed as superseded by this PR. All three bullseye-based images move here in one go.Note
This PR also carries an unrelated CI fix touching
.github/workflows/ci.yamlandbin/ci/test.sh, so the diff is wider than the title suggests.The
Test imagestep passed no GitHub credentials at all, so Composer inside the container reached github.com anonymously and failed whenever the shared runner IP was rate limited:It took out the
8.0leg twice while this PR was being verified. The token has to travel asCOMPOSER_AUTHinto the container, because that is where composer actually runs — a host-sidecomposer config github-oauth.github.com, the waybrowser-tests.ymldoes it, would never reach it.Kept here rather than in its own PR because a separate PR could not have reached green CI to prove the fix works.
Verified locally, all with
--no-cache:bin/ci/build.shfor every (php, node) pair in the matrix — 8.4/22, 8.3/22, 8.3/20, 8.0/20, 7.4/20, 7.3/20 — plus 8.1/20 and 8.2/20docker/Dockerfile-varnish7builds, reports Debian 12 with varnish 7.4.3 andlibvmod_xkey.soinstalledGenerate tokensucceeding on all 8 legs — run 34213936786For QA:
Review. The real check is the Varnish legs in ibexa/http-cache#90 and ibexa/dashboard#195 once this reaches
4.6— this repo's CI builds neither Varnish image (build.shonly buildsphp/Dockerfile-*), so both Varnish changes rest on local builds until then.What changes behaviourally, worth a sanity pass:
libicu(67 -> 72) and the rest of the system libraries change version.Dockerfile-varnish7moves Varnish 7.1 -> 7.4, with varnish-modules 0.20.0 -> 0.23.0. That is a real Varnish upgrade, not just a base OS bump —varnish7.vcland thexkeypurge path are what to exercise.Dockerfile-varnishmoves Debian 11 -> 12 but stays on Varnish 6.0.12, so only the base OS changes there.Documentation:
No documentation required.
🤖 Generated with Claude Code