Repository navigation
[quality] CI tool downloads have no curl --retry; a transient GitHub 500 fails the required test check #593
Description
Finding
A GitHub release-download returning HTTP 500 for a few seconds turns the required test check red. The curl calls that install hadolint, actionlint and just have no retry.
This happened on #592 at 878c2d6. The pull_request run (run 36539567569) failed in Install test tooling with:
curl: (22) The requested URL returned error: 500
##[error]Process completed with exit code 22.
The push run of the same commit (run 36539536808) passed. An empty commit, 7b9af41, then went green on both events. The PR's diff played no part.
The download is written the same way at eight sites, all using curl -fsSL -o with no --retry:
.github/workflows/ci.yml:47,:51,:55(hadolint, actionlint, just).github/workflows/ai-fix.yml:73,:77,:81(hadolint, actionlint, just).github/workflows/nightly-compliance.yml:55,:59(actionlint, just)
With --retry N, curl retries on a timeout and on HTTP 408, 429, 500, 502, 503 and 504, so the flake above would have been absorbed. Each download is followed by sha256sum -c, so a retry cannot swap in different bytes. The pins stay exactly as strict as they are now.
No test reads these lines: grep -n fsSL tests/*.py matches only fixtures in test_maintenance_audit.py and comments in test_atomic_image_builder.py. The suite needs no change.
Recommendation
It is one mechanical edit across the three files. At each of the eight sites, replace
curl -fsSL -o
with
curl -fsSL --retry 3 -o
For example, ci.yml:47 becomes:
curl -fsSL --retry 3 -o "$RUNNER_TEMP/bin/hadolint" \
https://github.com/hadolint/hadolint/releases/download/v2.14.0/hadolint-Linux-x86_64A single sed -i 's/curl -fsSL -o /curl -fsSL --retry 3 -o /' .github/workflows/{ci,ai-fix,nightly-compliance}.yml applies all eight. The curl mentioned in comments at ci.yml:114 and publish-wrapper.yml:7 is prose and does not match the pattern.
- all eight
curl -fsSL -osites inci.yml,ai-fix.ymlandnightly-compliance.ymlcarry--retry 3
Why no PR
Every change is under .github/workflows/. This agent's GitHub App token is minted at the contributor tier, which has no workflows permission, so GitHub rejects any push touching that directory. A human, or an agent running in ISSUES_PRS_MERGE mode, needs to land it. No part of the fix sits outside .github/workflows/.
Priority
- Impact: medium. It fails the required check on an unrelated PR, and this agent can't rerun jobs, so the only fix available is an empty commit, which moves a held PR's head.
- Effort: low (eight identical one-token insertions)
Filed by quality agent (hold-gated mode)
🐝 Hive Agent: quality | Instance: hive-wild-mole | SHA: 4e2cb3c
— hive: agent=quality backend=claude model=claude-opus-5-5 effort=medium claude=2.1.283
Activity
danathar-atomic-hive commentedon Sep 30, 2026
Checked again at
37beb34(main, 2026-09-29). Every line number in the body still holds, and nothing has landed a retry yet.The sed is safe against the repo's own download guards. With it applied to the three workflows,
python3 -m unittest discover -s tests -p "test_[wm]*.py"passes (test_workflow_dependencies.py+test_maintenance_audit.py, same result as unpatched main).ReleaseBinaryPinTestsparsescurl … -o <dest> <url>, andcurl -fsSL --retry 3 -o <dest> <url>still matches it, so every download stays visible and checksum-tied.Put the flag before
-o. Written ascurl -fsSL -o <dest> --retry 3 <url>, the flag lands between the destination and the URL. None of the parsers (_CURL,_CF_CURL,maintenance_audit.PINNED_DOWNLOAD_RE) match that form. In the workflows,test_every_release_url_is_in_a_recognised_download_formcatches it. In theContainerfile, only the count sentineltest_the_guards_above_can_see_the_file_they_read(expects exactly 3) catches it, and the weekly trust-root audit quietly stops checking any download written that way. I confirmed this by mutation: with the cosign download in that form,iter_pinned_downloadsreturned 2 instead of 3.Optional, same edit class:
Containerfile:57,:58and:85fetch the two repo keys and the cosign RPM with the samecurl -fsSL -o. Thecontainer-buildjob runs them viapodman build, so a transient 5xx there reds that job the same way. They are outside.github/workflows/, so this agent could push them. I haven't, because theContainerfileis the published image, which is production code and outside this lane. AddingContainerfileto the sed's file list covers them. With it included, the guards still pass anditer_pinned_downloadsstill finds all 3 pins.The workflow part still needs a human or an ISSUES_PRS_MERGE agent, for the reason given in the body.
🐝 Hive Agent:
quality| Instance:hive-wild-mole| SHA:unknown— hive: agent=quality backend=claude model=claude-opus-5-5 effort=medium claude=2.1.284