Unbreak main: harden CI apt updates and disable broken branch preview

[ikusteu]

What broke

main went red on the merge of #280, and #280 is not the cause. Nine jobs across four workflows died the same way, in the apt-get update step:

E: Failed to fetch https://dl.google.com/linux/chrome-stable/deb/dists/stable/main/binary-amd64/Packages.gz
   Hash Sum mismatch
E: Some index files failed to download. They have been ignored, or old ones used instead.
##[error]Process completed with exit code 100.

Google republished the Chrome repo's Release at 17:16Z naming one Packages.gz while serving another of the same length. GitHub's runner image preinstalls that apt source, so every step that runs apt-get update under set -e died — on jobs whose package list is entirely stock Ubuntu and which have no use for Chrome at all.

Failed: Lint, CI, Build + publish ExApp image, Deploy Preview. Deploy Preview was already red on the previous main commit for the same reason.

This has happened before. Three call sites in ci.yml already carry an rm naming packages.microsoft.com, with a comment describing exactly this failure. That is a deny-list of hosts we have already been burned by, and it only buys time until the next vendor. This is the next vendor.

The fix

Every apt package this repo installs in CI — jq, ffmpeg, shellcheck, xsltproc, libxml2-utils, ripgrep, python3-numpy — comes from the Ubuntu archive. So scripts/ci-apt-update.sh drops the sources that are not the Ubuntu archive, then updates against Ubuntu alone. All nine call sites use it, replacing the three host-specific removals.

The predicate keeps anything pointing at ubuntu.com rather than emptying the directory. That distinction is load-bearing: on Ubuntu 24.04 the main archive lives in /etc/apt/sources.list.d/ too, as the deb822 file ubuntu.sources. A pruner that wipes the directory leaves the runner unable to install anything, and I confirmed the layout before writing the rule.

Dropping a source list uninstalls nothing. The image's preinstalled Chrome, Node and gh stay exactly where they are; only which indexes apt fetches changes. A future job that genuinely wants a vendor package fails loudly on its own install, which is the right way round.

Reproduced and verified

What I could not reproduce: Google's corruption itself. I checked, and the index is healthy again — a fresh apt-get update against the real repo now exits 0. Synthesising the exact Hash Sum mismatch is not tractable, since apt only hard-fails it on a signed repo and only when the new Release names an index it has not cached. The four CI logs are the authoritative evidence for the failure.

What I did verify, on ubuntu:24.04 with the runner's source layout (ubuntu.sources plus the Google and Microsoft vendor lists):

[apt] dropping third-party source: google-chrome.list
[apt] dropping third-party source: microsoft-prod.list
[apt] kept 1 Ubuntu source(s), dropped 2 third-party source(s)
apt-get update exit=0

AFTER: ubuntu.sources

installed ok:
  jq /usr/bin/jq   xsltproc /usr/bin/xsltproc   xmllint /usr/bin/xmllint
  shellcheck /usr/bin/shellcheck   ffmpeg /usr/bin/ffmpeg   ffprobe /usr/bin/ffprobe

scripts/test-ci-apt-update.sh covers the predicate offline — temp-dir fixtures, no root, no apt, no network — so it belongs in the fast lint gate, where it is now listed. Eight cases: the two vendors that have actually broken main, every Ubuntu mirror host the runners use, lookalike hosts (notubuntu.com, archive.ubuntu.com.vendor.net), a mixed file, comment-only files, both source formats, files apt does not read, and a missing directory.

I mutation-tested it in both directions. A pruner that deletes everything fails 9 assertions including ubuntu.sources; a pruner that keeps everything fails 6 including both vendors.

Also run locally: shellcheck -x --source-path=SCRIPTDIR --severity=style over all 108 tracked scripts, actionlint over all 9 workflows, and the lint gate's script suite. The only local failure is test-prepare-synthetic-meeting.sh, which needs numpy that CI installs and I do not have.

Note

Because the upstream index has recovered, a plain re-run of main would likely go green on its own. That is the argument for this change rather than against it: the third time should not need a human to notice.

🤖 Generated with Claude Code

https://claude.ai/code/session_01VAMMNv8AJv6qe2xXWNh3Ju