Summary
The Build PHP workflow (.github/workflows/php.yml) has been failing since ~early December 2025. Last green run: #34 (2025-10-31, static-php-cli 2.7.6). First red run: #35 (2025-12-05, after #4 bumped static-php-cli to 2.7.9).
Despite the coincidence with the version bump, the failure is not caused by 2.7.9 — it's caused by CentOS 7 reaching EOL and the infrastructure around it changing. Reverting to 2.7.6 would fail the same way.
Root cause
static-php-cli's bin/spc-gnu-docker uses a centos:7 base image to produce a portable GNU toolchain. CentOS 7 went EOL on 2024-06-30 and its packages moved to vault.centos.org. Since roughly early December 2025, that host:
- 301-redirects HTTP → HTTPS (now behind CloudFront). CentOS 7's
yum does not follow redirects, so yum makecache / yum update fail.
- Serves a modern TLS certificate that the trust store shipped with
centos:7 can no longer validate. Even after bootstrapping past yum with sslverify=0, every subsequent curl inside the Dockerfile (patchelf, cmake, etc.) fails with Peer's Certificate issuer is not recognized (CentOS 7's curl is linked against NSS, not OpenSSL, so replacing /etc/pki/tls/certs/ca-bundle.crt alone does not help).
Reproduced locally with Docker against both 2.7.6 and 2.7.9.
Why no local workaround
A patch that rewrites repo URLs to HTTPS, sets sslverify=0 in yum and drops a /root/.curlrc with insecure would make the image build again, but it disables TLS validation on every external download inside the build container. Not acceptable for a binary that will ship into production images, and brittle enough that we'd rather not carry it.
Upstream status
- No upstream issue or PR specifically about the vault.centos.org redirect as of this writing.
- static-php-cli v3 (PR crazywhalecc/static-php-cli#980) deprecates CentOS 7 entirely. Maintainer confirmed the direction in #1050 ("deprecating CentOS 7 support" in v3). Related: #1027, #1049.
Decision
Wait for static-php-cli v3 and bump once it ships. Until then the Build PHP workflow is expected to fail on manual dispatch; existing published images are unaffected.
Action items
Summary
The
Build PHPworkflow (.github/workflows/php.yml) has been failing since ~early December 2025. Last green run: #34 (2025-10-31, static-php-cli 2.7.6). First red run: #35 (2025-12-05, after #4 bumped static-php-cli to 2.7.9).Despite the coincidence with the version bump, the failure is not caused by 2.7.9 — it's caused by CentOS 7 reaching EOL and the infrastructure around it changing. Reverting to 2.7.6 would fail the same way.
Root cause
static-php-cli'sbin/spc-gnu-dockeruses acentos:7base image to produce a portable GNU toolchain. CentOS 7 went EOL on 2024-06-30 and its packages moved tovault.centos.org. Since roughly early December 2025, that host:yumdoes not follow redirects, soyum makecache/yum updatefail.centos:7can no longer validate. Even after bootstrapping past yum withsslverify=0, every subsequentcurlinside the Dockerfile (patchelf, cmake, etc.) fails withPeer's Certificate issuer is not recognized(CentOS 7'scurlis linked against NSS, not OpenSSL, so replacing/etc/pki/tls/certs/ca-bundle.crtalone does not help).Reproduced locally with Docker against both 2.7.6 and 2.7.9.
Why no local workaround
A patch that rewrites repo URLs to HTTPS, sets
sslverify=0in yum and drops a/root/.curlrcwithinsecurewould make the image build again, but it disables TLS validation on every external download inside the build container. Not acceptable for a binary that will ship into production images, and brittle enough that we'd rather not carry it.Upstream status
Decision
Wait for static-php-cli v3 and bump once it ships. Until then the
Build PHPworkflow is expected to fail on manual dispatch; existing published images are unaffected.Action items
ref:in.github/workflows/php.ymland re-run the matrix.gcr.io/distroless/cc-debian12:nonroot.