Repository navigation
ci: install ffmpeg through the GitHub API asset route with a cache - #7401
Conversation
Edit accuracy: accurate 267 (base branch 267), smooth 98 of thoseThe gate passes. Quarantined, measured but not gated (8)
Unstable (2)
|
![heygengenesis[bot]](https://avatars.githubusercontent.com/in/2913576?s=60&v=4){kind=small}
There was a problem hiding this comment.
Verdict: REQUEST CHANGES · 1 blocker · 0 important · 1 nit · head c1d49a20
- blocker (PR body): this is a fix PR, so the body needs a
fails without the fix:line naming the check that fails without it. For example:fails without the fix: SDK: unit + contract + smoke (setup 504 from releases/download, run <link>). Adding that line clears this; I found nothing wrong in the code.
Scope
Read the full diff (install-ffmpeg-linux/action.yml, ci.yml). The cache key is the pinned sha256, and the restored file is hashed again before use, so a poisoned cache can't get through. A failed id lookup or a partial download falls through to a retry, and the loop ends at the bounded exit. Every caller uses the default release-url, so the github.com sed parse holds. The callers run with contents: read on a public repo, and GITHUB_TOKEN can read the BtbN public release. No caller uses container:, so gh is on PATH. CI on this head is green, and the SDK job log shows Cache hit for: ffmpeg-linux-26d2ecd0… followed by a working ffmpeg -version.
| } | ||
| for attempt in 1 2 3 4; do | ||
| verified && break | ||
| [ "$attempt" = 4 ] && { echo "ffmpeg download failed four times" >&2; exit 1; } |
There was a problem hiding this comment.
nit: fetch runs at most three times (attempts 1–3), because attempt 4 only re-checks the hash. The message says "four times", which will mislead whoever reads a failed setup log.
| [ "$attempt" = 4 ] && { echo "ffmpeg download failed four times" >&2; exit 1; } | |
| [ "$attempt" = 4 ] && { echo "ffmpeg download failed three times" >&2; exit 1; } |
What
The Linux jobs fetch their pinned ffmpeg through the GitHub API asset route instead of
github.com/.../releases/download, check its sha256, and cache the tarball keyed on that sha256.Why
On 2026-11-08 about 14 jobs on one PR died in setup with
curl: (22) The requested URL returned error: 504from the release download URL, and a rerun 40 minutes later failed the same way.fails without the fix: SDK: unit + contract + smoke (setup 504 from github.com releases/download, https://github.com/heygen-com/hyperframes/actions/runs/42470531186/job/128700038635); also Test (runtime), Test (cli 1/2), CLI smoke (required) on #7398 at 6aad021.
Related work
Unblocks the red checks on #7398, which are not caused by its diff.
How
install-ffmpeg-linux: looks up the asset id for the pinned file name in the pinned release, downloads it withgh api(Accept: application/octet-stream), retries up to three times with a growing pause, and verifies the same sha256 as before. Therelease-urlinput stays the single pin, so the Dockerfile pins still match.actions/cache(same pinned action as the other workflows) keeps the tarball underffmpeg-linux-<sha256>; a hit skips the download.ffmpeg-static's postinstall fetches from releases unless a file exists atFFMPEG_BIN.catalog-payloads,sdk-testsandstudio-timeline-viewportwere the three Linuxci.ymljobs that ran the install without the ffmpeg steps the others use; they now runinstall-ffmpeg-linuxandprepare-ffmpeg-binfirst. Thecatalog-publishworkflow and the multi-OS npx-shim job still download it (a release path and a Windows/macOS matrix).oven-sh/setup-bunalso fetches from releases and had one 504 in the same window; it is an external action, so it needs its own change.git grep -n "releases/download" .github): only this action.Test plan
Size
Size: a lone CI fix for the GitHub release download outage; nothing open can carry it.