ci: bound every job, and stop apt waiting forever on a stalled mirror - #4
Merged
Merged
Conversation
Two runs of this workflow burned to GitHub's 6-hour default timeout without producing a result. Neither failed: both hung inside apt, which by default waits indefinitely on a mirror connection that has gone quiet. One lost an hour on `apt-get install zip`, the other six hours split across dependency installs. Different packages, same cause, so the fix is applied at the transport rather than at each call site. Two layers, because either alone leaves a hole: 1. `timeout-minutes` on every job. Without it a stall is only noticed six hours later, by which point the run is worthless and the queue has been held. The values are roughly 3x the observed wall time of each job, so a slow-but-healthy run is never killed. 2. `UR_APT_OPTS` in the workflow env, threaded through every apt invocation: `Acquire::Retries=3` covers the transient 503s the Azure mirrors serve under load, and the http/https `Timeout=30` options are what actually convert a silent stall into a fast, legible failure. `No-Cache=true` keeps a proxy from serving a stale index that then 404s on download. No dependency versions change and no step is added or removed; this is entirely about how the existing steps fail.
Ryanmello07
marked this pull request as ready for review
August 21, 2026 15:39
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
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.
Two runs of this workflow burned to GitHub's 6-hour default without producing a
result. Neither failed — both hung inside apt, which by default waits
indefinitely on a mirror connection that has gone quiet. One lost an hour on
apt-get install zip; the other lost six hours split across dependencyinstalls. Different packages, same cause, so this is fixed at the transport
rather than at each call site.
Two layers, because either alone leaves a hole:
timeout-minuteson every job. Without it, a stall is only noticed sixhours later, by which point the run is worthless and the queue has been held.
The values are roughly 3× each job's observed wall time, so a slow-but-healthy
run is never killed.
UR_APT_OPTSin the workflow env, threaded through every apt invocation:Acquire::Retries=3— covers the transient 503s the Azure mirrors serveunder load.
Acquire::http::Timeout=30/https::Timeout=30— the options thatactually convert a silent stall into a fast, legible failure.
Acquire::http::No-Cache=true— keeps a proxy from serving a stale indexthat then 404s on download.
No dependency versions change, and no step is added or removed. This is entirely
about how the existing steps fail.
Why this is split out on its own
It is the only change in this series that touches nothing but CI mechanics: no
source file, no packaging file, no product decision. It is independent of the
app-ID rename that PRs 2–6 build on, and it is worth landing before them so
their runs fail in minutes instead of hours.
Note for whoever merges second
PR 4 (
upstream/appstream-metainfo) also edits theguijob — it appendsappstreamto the same apt package list and adds a validation step at the end.The two were written against
mainindependently and merge cleanly in testing,but if git ever disagrees, the resolution is "keep both": this PR's
$UR_APT_OPTSon theapt-getlines, and PR 4's extra package plus extra step.