ci(vcpkg): Repair the vcpkg CI path and move the binary cache to GitHub Packages - #2542
ci(vcpkg): Repair the vcpkg CI path and move the binary cache to GitHub Packages#2542bobtista wants to merge 6 commits into
Conversation
We use ephemeral GitHub-hosted runners, do we need to worry about this? Every job starts with a clean NuGet config |
|
What is now the strategy with vcpkg? We still have it disabled because it caused long CI build times every now and then. |
The strategy is to move the dependency build output into the GitHub Packages NuGet binary cache instead of continuing with handmade caching tweaks trying to use actions/cache as a big shared folder cache. We should have used nuget from the beginning - Microsoft’s vcpkg docs specifically recommend the NuGet provider for this use case. I tested this on my fork. The first GenCI run still took about 24 minutes for the vcpkg jobs, which I think is expected because it had to build/populate the cache. Then I ran the same workflow again on the same commit, and the vcpkg jobs dropped to about 5.5-8 minutes. The CMake configure step was only around 30-45 seconds on the second run, so ffmpeg was restored from the cache instead of rebuilt. The workflow is still red on my fork because the replay checks need R2 secrets I don’t have set up, but all six win32-vcpkg build variants passed on both runs. |
68cdb82 to
8e918ef
Compare
|
Rebased onto main and updated the PR, updated the description here too - this is ready for review and merge IMHO |
8e918ef to
553b91e
Compare
The baseline had not moved since March 2025. MSYS2 mirrors purge superseded packages, so the msys2-runtime pinned by that vcpkg tree now 404s on every mirror and any cold build of ffmpeg fails. The 2026.07.29 tree pins a runtime that is still published.
Disabling compiler tracking removed the compiler from the ABI hash, so a runner image update could restore binaries built by a different MSVC. It was a workaround for hand-written cache keys invalidating on every image update. The NuGet binary cache addresses that directly, keyed by vcpkg's own ABI hash, so the workaround is no longer needed and a compiler bump can rebuild once.
A change touching only vcpkg.json or triplets produced no build jobs, so a baseline or triplet edit could land without ever being compiled.
The file is not vcpkg's lockfile format and nothing reads it. Dependency versions are resolved from builtin-baseline and overrides in vcpkg.json, so the checked-in file only suggested a version pinning that was not in effect.
553b91e to
4a2d650
Compare
f7fcd60 to
4a2d650
Compare
|
Found the reason the downloads were failing - a retired link 😆 This can be merged now to turn vcpkg back on, the caching works, and I added a follow up PR that gates ffmpeg so it only gets built when it's being used. That's the majority of the build time on cold builds |
The vcpkg builds were failing on a dead download link. ffmpeg needs an MSYS2 runtime package, and MSYS2 deletes old versions once a newer one supersedes them. We were still asking for the deleted one because
builtin-baselinehad not moved since March 2025, and the baseline pins the vcpkg tree that lists those package versions.Now the binary cache is a NuGet feed on GitHub Packages keyed by vcpkg's own ABI hashes, so there is no hand-written cache key to invalidate and no save race. Compiler tracking is back on, the baseline is the 2026.07.29 release, both paths are in the filter, and
vcpkg-lock.jsonis removed since nothing reads it and it is not vcpkg's lockfile format. Fork pull requests are set toread, since their token cannot upload.I warmed the feed with a
workflow_dispatchon a temporary branch, so the checks here already restore from it: 10 packages in under 6 seconds and vcpkg builds in 6 to 9 minutes, against 26 cold.Follow-up: #3184 closes #3175 by making ffmpeg an opt-in vcpkg feature, so default cold builds no longer spend most of their time building a dependency that is not linked.
Todo:
workflow_dispatchruns on a fork: cold builds in about 26 minutes, warm restores 10 packages in 3.5s and builds in about 7min