GH Actions: work around intermittent apt-get errors #45
Conversation
This file contains 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
wimg
approved these changes
Apr 24, 2024
Okay, so apparently, there is a long-standing bug in the Microsoft package deploy process which caused `apt-get update` to fail in the first half hour after Microsoft has deployed a package. The failure looks like this: ``` E: Failed to fetch https://packages.microsoft.com/ubuntu/22.04/prod/dists/jammy/InRelease Clearsigned file isn't valid, got 'NOSPLIT' (does the network require authentication?) ``` As this only happens intermittently (after a MS package deploy), the chance of running into this bug are slim, but guess what: today I ran into it. This change to the workflow is intended to prevent the next person running into this issue from having to waste time on figuring this out. By splitting the "Install xmllint" step into two steps: one doing the `apt-get update` and one doing the actual install and making the first step one which is allowed to `continue-on-error`, this issue should hopefully not crop up anymore. Any errors in the `apt-get update` step will now be ignored and as most errors which could potentially come from that step are irrelevant for the rest of the job anyway, this is fine. If a relevant error would be surfaced, the next step (the xmllint install), will fail the job anyway. Refs: * actions/runner-images#3410 * dotnet/core#4167
jrfnl
force-pushed
the
feature/ghactions-xmllint-bypass-apt-get-update
branch
from
dead9d6
to
0d82f23
Compare
|
Rebased without changes to get a passing build (well, passing except for against PHPCompatibility 10, but that's expected) |
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.
Okay, so apparently, there is a long-standing bug in the Microsoft package deploy process which caused
apt-get updateto fail in the first half hour after Microsoft has deployed a package.The failure looks like this:
As this only happens intermittently (after a MS package deploy), the chance of running into this bug are slim, but guess what: today I ran into it.
This change to the workflow is intended to prevent the next person running into this issue from having to waste time on figuring this out.
By splitting the "Install xmllint" step into two steps: one doing the
apt-get updateand one doing the actual install and making the first step one which is allowed tocontinue-on-error, this issue should hopefully not crop up anymore.Any errors in the
apt-get updatestep will now be ignored and as most errors which could potentially come from that step are irrelevant for the rest of the job anyway, this is fine. If a relevant error would be surfaced, the next step (the xmllint install), will fail the job anyway.Refs: