Repository navigation
chore(build): point the FFmpeg artifact at v0.3.0, and never rebuild a published one - #42
Merged
Merged
Conversation
…a published one
v0.3.0 is the first release whose xcframework links dav1d, and the
version itself should resolve to it — not only a later patch release.
The checksum can only exist once the release job has built the
artifact, so the drill is: tag, let the job attach the zip, point
Package.swift at it, then move the tag onto this commit.
The checksum was not copied from CI: the published zip was downloaded
and run through `swift package compute-checksum`, which reproduces the
attached FFmpeg.xcframework.zip.checksum exactly:
4aed787a0cf05067395bb5b07f1af96c25e1314a841bc1597e37964dd009b5b0
The artifact carries all ten architectures (seven xcframework slices,
the macOS and iOS/tvOS simulator ones fat with x86_64), and dav1d is
linked into every one of them (749 exported dav1d symbols each).
Moving the tag re-runs the release job, which would rebuild — not
bit-identically — and replace the published zip, breaking the checksum
pinned here. The job now skips itself when the release already carries
FFmpeg.xcframework.zip. AGENTS.md and CONTRIBUTING.md describe the
drill; CONTRIBUTING's download size (~270 MB) was stale — it is ~125 MB.
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.
Summary
Makes v0.3.0 itself resolve to its own FFmpeg artifact, the first build that links dav1d. Previously that would only have happened in a follow-up patch release, as with v0.2.0 → #36 → v0.2.1.
The checksum can only exist once the release job has built the artifact, so the drill is:
v0.3.0(done; the release job attached the xcframework);Package.swiftat that URL and checksum;v0.3.0tag onto the merge commit.The guard. Moving the tag re-runs the release job. Before this PR it would rebuild the xcframework, which is not bit-identical, and replace the published zip, breaking the checksum pinned here for everyone. The release job's new first step skips the whole job when the release already carries
FFmpeg.xcframework.zip. That also protects every future release from an accidental re-push. AGENTS.md and CONTRIBUTING.md describe the drill.Verification
The checksum was not copied from CI. The published zip was downloaded and run through
swift package compute-checksum, which reproduces the attachedFFmpeg.xcframework.zip.checksumexactly:The artifact carries all ten architectures, and dav1d is linked into each:
The URL path was exercised end to end with a fresh clone of this branch and no
BinaryDependencies/directory, which forces SwiftPM downbinaryTarget(url:checksum:):The guard itself can only be exercised by the tag move, since the job only runs on tags. I'll check that run and confirm the published zip and checksum are unchanged afterwards.
Also fixed: CONTRIBUTING's download size (~270 MB) was stale; it's ~125 MB.