Fix workflow timeout with revised apt-get source replacements #603
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.
This PR replaces some of the
Workaround for sources.list
steps, addressing the unexplained timeouts when workflows get stuck duringapt-get update
. My personal opinion, without proof, is that there's an (undocumented) azure throttle.It appears that over time, the actual sources were changed. None of the workarounds were actually doing replacements that the system used. Enclosed is a common block fix for most environments.
The current expected replace needed is probably only in
/etc/apt/apt-mirrors.txt
. (seems to vary with Ubuntu version)In order to spread the bandwidth joy, this PR fixes
azure.archive.ubuntu.com
replacements withmirror.arizona.edu
for only HALF of the workflow instances. The remainder will use the default azure source.No timeout adjustments are included. (see below)
(original PR text for reference)
Adjusts the workflow timeout from 15 minutes to 30 minutes. (see my recent #600)
Yesterday, I thought perhaps it was an intermittent azure/unbutu problem when doing an
agp-get update
after waiting 2+ hours.I'm not convinced that this is a job timeout problem. All of the workflows that were cancelled ended during the install phase. The install typically completes in 2 minutes.
Depending on the plan, there are Job concurrency limits for GitHub-hosted runners, also some maximums for workflows.
In any case, let's try 30 minutes here in this PR.
edit: see also: actions/runner-images#12949