All four downloads in scripts/download-ollama.sh use curl -L without --fail, so an HTTP
error is written to disk as if it were the artifact. Only the macOS ffmpeg branch validates
what it got; the Windows and Linux ffmpeg branches and the Ollama download do not.
What it looks like when it bites
Build backend bundle (Windows) on #441 failed like this:
100 9 100 9 0 0 69 0
End-of-central-directory signature not found. Either this file is not
a zipfile, or it constitutes one disk of a multi-part archive.
unzip: cannot find zipfile directory in one of ffmpeg.zip or
ffmpeg.zip.zip, and cannot find ffmpeg.zip.ZIP, period.
##[error]Process completed with exit code 9
Nine bytes — the length of Not Found. The GitHub release redirect returned an error page,
curl happily saved it as ffmpeg.zip, and unzip produced an error that says nothing about a
failed download. The asset was fine: the same URL returns 200 and a 168 MB zip on retry, and
the job passed on a re-run. So the underlying event was transient; what made it expensive was
that the failure surfaced three steps away from its cause.
Run: https://github.com/ruzin/stenoai/actions/runs/30274798683/job/90006009060
Where the gap is
| Download |
--fail |
validated after extract |
ffmpeg, macOS (:26) |
no |
yes — asserts arm64 Mach-O and pins ffmpeg version 7.1 |
ffmpeg, Linux (:57) |
no |
no |
ffmpeg, Windows (:70) |
no |
no |
Ollama, all platforms (:115) |
no |
no |
The macOS branch already carries a comment explaining exactly this failure mode ("Truncated/
corrupt download or wrong-format extract"). The guard just never made it to the other
branches.
Suggested fix
Two small things, no behaviour change on the happy path:
curl --fail --retry 3 --retry-delay 2 -L for all four. --fail turns an HTTP error into
a non-zero exit instead of a saved error page, and the retries absorb exactly the class of
blip seen above.- Give the Windows and Linux ffmpeg branches, and the Ollama extract, the same
post-conditions the macOS branch has — at minimum that the expected binary exists and runs.
ffmpeg.exe -version is enough to catch a truncated or wrong-format archive.
A size floor before extracting would also work and is cheaper than a run check on Windows,
where the binary cannot be executed on a Linux runner.
Why it matters beyond one red job
Every Windows release build and every t2-windows / t2-pipeline-windows run depends on this
script. Today a transient CDN hiccup fails them with an error that reads like a corrupt
archive, which costs a maintainer a log dive to reach "just re-run it". With --fail the same
event would say curl: (22) The requested URL returned error: 404 on the line that caused it.
Found while watching CI on #441; unrelated to that PR's contents.
All four downloads in
scripts/download-ollama.shusecurl -Lwithout--fail, so an HTTPerror is written to disk as if it were the artifact. Only the macOS ffmpeg branch validates
what it got; the Windows and Linux ffmpeg branches and the Ollama download do not.
What it looks like when it bites
Build backend bundle (Windows)on #441 failed like this:Nine bytes — the length of
Not Found. The GitHub release redirect returned an error page,curl happily saved it as
ffmpeg.zip, andunzipproduced an error that says nothing about afailed download. The asset was fine: the same URL returns 200 and a 168 MB zip on retry, and
the job passed on a re-run. So the underlying event was transient; what made it expensive was
that the failure surfaced three steps away from its cause.
Run: https://github.com/ruzin/stenoai/actions/runs/30274798683/job/90006009060
Where the gap is
--fail:26)ffmpeg version 7.1:57):70):115)The macOS branch already carries a comment explaining exactly this failure mode ("Truncated/
corrupt download or wrong-format extract"). The guard just never made it to the other
branches.
Suggested fix
Two small things, no behaviour change on the happy path:
curl --fail --retry 3 --retry-delay 2 -Lfor all four.--failturns an HTTP error intoa non-zero exit instead of a saved error page, and the retries absorb exactly the class of
blip seen above.
post-conditions the macOS branch has — at minimum that the expected binary exists and runs.
ffmpeg.exe -versionis enough to catch a truncated or wrong-format archive.A size floor before extracting would also work and is cheaper than a run check on Windows,
where the binary cannot be executed on a Linux runner.
Why it matters beyond one red job
Every Windows release build and every
t2-windows/t2-pipeline-windowsrun depends on thisscript. Today a transient CDN hiccup fails them with an error that reads like a corrupt
archive, which costs a maintainer a log dive to reach "just re-run it". With
--failthe sameevent would say
curl: (22) The requested URL returned error: 404on the line that caused it.Found while watching CI on #441; unrelated to that PR's contents.