Weekly base-image build fails: chrome-headless-shell 404 on linux/arm64 (upstream Quarto/Playwright CDN bug) #29

Summary

The weekly scheduled Publish base image workflow (.github/workflows/publish-image.yml) fails in the publish job's "Build and push" step, on the linux/arm64 build leg only. linux/amd64 builds fine.

The failure happens inside Dockerfile.base, on the quarto install chrome-headless-shell --no-prompt line.

Exact error:

download failed (HTTP status 404 - Not Found)

Timeline

• 2026-09-07 – First seen, in run Pre-render all mermaid diagrams #13.
• 2026-09-14 – Confirmed still broken. Reproduced across two independent from-scratch builds, so this is not a transient/flaky failure.

Root cause

Playwright restructured its Chrome-for-Testing CDN URL layout in early September 2026:

• Old path: builds/chromium/{revision}/chromium-headless-shell-linux-arm64.zip
• New path: builds/cft/{browserVersion}/linux-arm64/...

Quarto v1.9.38's installer still constructs the old, now-404ing URL when installing chrome-headless-shell for arm64.

This is tracked upstream:

• quarto install chrome-headless-shell fails on Linux arm64 with 404 (stale Playwright CDN URL) quarto-dev/quarto-cli#14857 (bug report)
• Fix chrome-headless-shell install on Linux arm64 quarto-dev/quarto-cli#14860 (fix PR)

As of 2026-09-14, no stable Quarto release contains the fix. v1.10.18 predates it, and v1.11.4 is pre-release only.

Decision / plan

• Wait for a stable Quarto release that includes the fix from PR #14860, then bump QUARTO_VERSION in Dockerfile.base to that version.
• Do not add retry/wget-retry logic around this install step — a 404 from a moved URL will fail identically on every retry, so retries won't help.
• Do not touch the R_VERSION pin — that's unrelated to this issue (see the existing R_VERSION 4.5.2 pin history / PR Revert to R 4.5.2 and formalize release tagging #21 for context if useful).

Caveat on verifying a fix

A manual workflow_dispatch re-run can appear to "succeed" via a cached Docker layer without actually re-testing the download — only the scheduled cron event forces --no-cache. So don't treat a green non-scheduled re-run as confirmation this is fixed. Check that the "Build and push" step actually took several minutes (real build), not just seconds (cache hit), before concluding it's resolved.

Next steps

• Check quarto-cli releases for a version containing PR #14860 landing, then bump QUARTO_VERSION in Dockerfile.base and verify the weekly scheduled build (or a workflow_dispatch run with cache disabled) succeeds for both architectures.