Fix CI dependency caching: per-platform cache keys and fallbacks [androidbuild] [iosbuild]

[ptesavol]

You suspected the dependency caching does not really work in our CI runs — the suspicion was correct, and the evidence is unambiguous.

What was wrong

The cache key was built from the runner's processor architecture and operating system plus a hash of the dependency manifests. But three different jobs run on the same macOS runner image: the normal macOS build, the iOS build and the Android build. They therefore computed the same cache key while needing completely different dependency sets. GitHub's cache is write-once per key, so the first job to save — always the fast host build — owned the key forever, and the iOS and Android saves were rejected on every run (the "Cache save failed." messages visible in the logs).

Measured impact: every Android run spends twenty-three to thirty-one minutes and the iOS run thirty-five minutes, because their cross-compiled dependencies (folly, protobuf, openssl and the rest) are rebuilt from source every single time. The host macOS build, whose cache works, takes fourteen minutes.

Two further weaknesses fixed along the way: there was no fallback key, so any change to the dependency manifests or overlay files threw away the entire cache instead of reusing most of it; and the vcpkg tool's own version was not part of the key, so a tool upgrade silently reused stale installed trees.

The fix

• The target platform (host, iOS or Android) is now part of both cache keys, so each platform owns its own cache and all saves succeed.
• Fallback keys: on any exact miss the newest previous cache for the same platform is restored — vcpkg's own per-package hashing makes stale entries harmless, so a manifest change now rebuilds only what actually changed.
• The vcpkg tool version (submodule commit) is part of the exact key.

What to expect

The first run with the new keys — this pull request, which runs all five platforms via the title keywords — is a deliberate cold build that populates each platform's cache for the first time. The improvement shows from the next run onwards: Android should drop from about thirty minutes to roughly twelve to fifteen, iOS similarly, since dependency installation becomes a quick unpack of cached binaries.

About the tutorial you linked (binary caching via GitHub Packages)

It is the right long-term design and this repository qualifies for it well (public repository, so the package storage is free). It gives per-package cache granularity in a registry with no total-size limit and no write-once semantics. I recommend it as a follow-up if the fixed key scheme proves insufficient — the five per-platform caches together may approach GitHub's ten-gigabyte total cache budget, and if evictions start appearing, the registry-based cache is the escape. The reasons not to jump straight to it: it needs the NuGet client on all runners (including installing it on your self-hosted Linux machine), token wiring with package-write permission, and this small fix likely captures most of the benefit already.

🤖 Generated with Claude Code

[cursor]

Bugbot is not enabled for this team, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[cursor]

Bugbot is not enabled for this team, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.