Stopped apt-get update being the gate it was never meant to be - #7
Merged
fdesbiens merged 1 commit intoSep 9, 2026
Merged
Conversation
A release build went red because Google's Chrome apt repository served a Packages.gz that did not match its own Release file -- their CDN caught mid-publish, the index eight hours older than the manifest describing it. apt-get update fails if ANY configured repository serves a bad index, so install.sh failed three attempts running, and nothing was built. Verified as theirs rather than ours, from a second machine: the Release file asks for 233e56de and the Packages.gz they serve hashes to bc1428ab, which are the two hashes in the failing log. Not a runner glitch and not a network blip; retrying gets the same answer until they republish. Nothing in this project installs a browser. The runner image happens to carry that repository and Microsoft's, and one of them being broken is now enough to stop a build that needs neither. SO THE UPDATE WARNS AND THE INSTALL IS THE GATE. Nothing is weakened by that. apt-get install still fails hard on a package it cannot find, so an archive that is genuinely unreachable still stops the script -- one step later, and naming the package it could not get, which is a better diagnostic than a hash mismatch in a repository nobody asked for. THE OBVIOUS ALTERNATIVE IS WORSE AND IS NOT TAKEN. Disabling third-party sources before updating would make the update strict again, and this script also runs on a contributor's own machine, where silently rewriting their apt configuration to suit our CI would be a considerably worse thing to do than tolerating a stale index for a repository we do not read. Verified in both directions: a failing update warns and execution continues past it, and a genuine command failure still aborts under set -e. Assisted-by: Claude Code (Opus 5) <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
1 participant
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.
mainwent red on the Phase-0 release merge, and the cause was outside this project.Google's Chrome apt repository served a
Packages.gzthat did not match its ownReleasefile — their CDN caught mid-publish, with the index eight hours older than the manifest describing it.apt-get updatefails if any configured repository serves a bad index, soinstall.shfailed three attempts running and nothing was built.Verified as theirs rather than ours, by fetching both files from a second machine:
Releaseasks for233e56de…Packages.gzthey servebc1428ab…Those are the two hashes in the failing log. Not a runner glitch and not a network blip — a re-run got the same answer, and it will until they republish.
Nothing in this project installs a browser. The runner image happens to carry that repository and Microsoft's, and one of them being broken was enough to stop a build that needs neither.
The change
apt-get updatenow warns instead of aborting, andapt-get installis the gate.Nothing is weakened.
apt-get installstill fails hard on a package it cannot find, so an archive that is genuinely unreachable still stops the script — one step later, and naming the package it could not get, which is a better diagnostic than a hash mismatch in a repository nobody asked for.The alternative that is not taken
Disabling third-party sources before updating would make the update strict again. It is not done, because
install.shalso runs on a contributor's own machine, and silently rewriting someone's apt configuration to suit our CI would be a considerably worse thing to do than tolerating a stale index for a repository we do not read.Verification
Both directions: a failing update warns and execution continues past it, and a genuine command failure still aborts under
set -euo pipefail.