Skip to content

Conversation

@bobtista
Copy link

@bobtista bobtista commented Dec 22, 2025

Somehow, the cache keys changed in the last two weeks, and an empty cache (189 bytes) was stored, causing all subsequent runs to "hit" an empty cache.

Identified several opportunities to improve it while troubleshooting:

  • lukka/run-vcpkg@v11 sets a default temp directory, even when its caching is disabled. Explicitly overrode VCPKG_DEFAULT_BINARY_CACHE to ensure vcpkg always uses our persistent cache directory
  • Include MSVC compiler version in the cache key to prevent cross-toolchain cache reuse
  • Split cache restore and save steps for clearer control and observability
  • Validate cache contents before saving to avoid writing empty caches
  • Versioned the cache key (v2) to cleanly break from the poisoned cache

Build time is back down at 6 minutes again

@bobtista bobtista changed the title ci(vcpkg): Override VCPKG_DEFAULT_BINARY_CACHE to use our cache directory ci(vcpkg): Fix binary cache again Dec 22, 2025
@bobtista bobtista changed the title ci(vcpkg): Fix binary cache again ci(vcpkg): Stabilize vcpkg binary caching (compiler-aware keys, explicit cache path) Dec 22, 2025
@bobtista bobtista marked this pull request as ready for review December 22, 2025 22:00
@xezon
Copy link

xezon commented Dec 22, 2025

Thanks for sending another fix. It is quite absurd that vcpkg cache breaks every month. All this new code you added, is all this totally necessary? Complexity looks outrageous and not human readable.

@bobtista bobtista force-pushed the bobtista/vcpkg-cache-override branch from 0792367 to 4adbf76 Compare December 22, 2025 22:58
@bobtista
Copy link
Author

Thanks for sending another fix. It is quite absurd that vcpkg cache breaks every month. All this new code you added, is all this totally necessary? Complexity looks outrageous and not human readable.

I removed some of the debugging lines. There's one potentially optional part that makes it so only one of the build jobs tries to save to the cache may be optional, but I think it avoids the errors when all 6 jobs try to write at the same time and only one succeeds.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants