Re-pin ffmpeg to a build that still exists - #48
Merged
Merged
Conversation
Cutting 0.2.0 failed at Package. Nothing in the repository had changed: BtbN deletes its autobuild releases after roughly two weeks, so the asset the digest pins had simply gone and the download 404ed. The pin rots on a timer whether or not anyone cuts a release. Refreshed to the newest autobuild on the same ffmpeg branch — n8.1.2-40-g852b0552f0 to n8.1.2-50-g1a748fe2cd, ten upstream commits on 8.1, not a move to 9.0. A broken link is not a reason to change encoder branches, and the conservative refresh is the one that keeps the shipped build close to what was tested. Re-pinning needed no 146 MB download. GitHub's releases API carries a digest per asset, so the sha256 came straight out of the API, and the asset's short commit resolved against FFmpeg/FFmpeg gives sourceCommit and the source archive the release is obliged to attach. Verified both new URLs return 200 and the old asset returns 404, so the diagnosis is the whole story rather than a guess that happened to work. The manifest now says all of that in its own comment block, because the next 404 should cost a minute rather than an afternoon, and because the tempting fix — switching branches, or deleting the digest check — is the wrong one twice over. Why no test caught it: CI runs the encode tests against gyan.dev, a different distributor with durable versioned URLs, and CI's installer job stages a stand-in ffmpeg.exe on purpose, since it is testing the packaging layout rather than a large download. fetch-ffmpeg.ps1 is therefore the only step in the pipeline that runs for real just once per release. Recorded as a Phase 8 finding, along with the dispatch build that would have found it without spending a version number. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
revtex
added
the
no-changelog
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
v0.2.0failed at thePackagestep. Nothing in the repository had changed: BtbN deletes itsautobuild releases after roughly two weeks, so the asset the digest pins was gone and the download
404ed. The pin rots on a timer whether or not anyone cuts a release.
Refreshed to the newest autobuild on the same ffmpeg branch —
n8.1.2-40-g852b0552f0→n8.1.2-50-g1a748fe2cd, ten upstream commits on 8.1, not a move to 9.0. A broken link is not areason to change encoder branches.
Re-pinning needed no 146 MB download: GitHub's releases API carries a
digestper asset, so thesha256 came from the API, and the asset's short commit resolved against
FFmpeg/FFmpeggivessourceCommitand the source archive the release is obliged to attach. The digest check infetch-ffmpeg.ps1is untouched and still fails loudly on a mismatch.Why nothing caught it
CI runs the encode tests against gyan.dev — a different distributor, with durable versioned
URLs — and CI's installer job stages a stand-in
ffmpeg/ffmpeg.exeon purpose, because it istesting the packaging layout rather than a large download. So
fetch-ffmpeg.ps1is the one step inthe pipeline that only runs for real at tag time.
workflow_dispatchwith a-devversion buildseverything and publishes nothing, and is the cheap way to find this without spending a version
number. Both facts are now a Phase 8 finding, and the manifest carries a comment on how to re-pin.
no-changelogThe bundled ffmpeg moves ten commits along the same stable branch; no Offstream behaviour changes,
and the release notes state the exact ffmpeg version automatically from the manifest, so the fact
reaches users without the changelog repeating it.
🤖 Generated with Claude Code