Getting cache hit even when changing appendedCacheKey

If I change appendedCacheKey between runs I still get a cache hit.

Here I changed the append key to debug-20710ef73d32fa66a66a4fb0ed803cdce8b4099f55c53e82b7de0ec2a6fbf743-v2 for this run. It picks up the Cache key properly Cache key: 'runnerOS=win2220220306.1-vcpkgGitCommit=5962cf5a3bfc2124e8de991a4e45a8edcb3b4c69_appendedKey=debug-20710ef73d32fa66a66a4fb0ed803cdce8b4099f55c53e82b7de0ec2a6fbf743-v2' but then it says Cache restore keys: 'runnerOS=win2220220306.1-vcpkgGitCommit=5962cf5a3bfc2124e8de991a4e45a8edcb3b4c69' and then Cache hit, key = 'runnerOS=win2220220306.1-vcpkgGitCommit=5962cf5a3bfc21[24](https://github.com/EpicGames/zen/runs/5598118276?check_suite_focus=true#step:4:24)e8de991a4e45a8edcb3b4c69_appendedKey=release-20710ef73d32fa66a66a4fb0ed803cdce8b4099f55c53e82b7de0ec2a6fbf743'. which is wrong?

Or does it deem them to be the same?

I’m running this in a private repo so sadly I can’t give you access to the full build log.

Restore vcpkg and its artifacts from cache
  Cache key: 'runnerOS=win2220220306.1-vcpkgGitCommit=5962cf5a3bfc2124e8de991a4e45a8edcb3b4c69_appendedKey=debug-20710ef73d32fa66a66a4fb0ed803cdce8b4099f55c53e82b7de0ec2a6fbf743-v2'
  Cache restore keys: 'runnerOS=win2220220306.1-vcpkgGitCommit=5962cf5a3bfc2124e8de991a4e45a8edcb3b4c69'
  Cached paths: 'D:/a/zen/b/vcpkg_cache,D:\a\zen\zen\vcpkg,!D:\a\zen\zen\vcpkg\installed,!D:\a\zen\zen\vcpkg\vcpkg_installed,!D:\a\zen\zen\vcpkg\packages,!D:\a\zen\zen\vcpkg\buildtrees,!D:\a\zen\zen\vcpkg\downloads'
  Cache Size: ~1001 MB (1049780280 B)
  C:\Windows\System32\tar.exe -z -xf D:/a/_temp/e7d[23](https://github.com/EpicGames/zen/runs/5598118276?check_suite_focus=true#step:4:23)e4a-1f59-4550-a2e9-d05d01f2df12/cache.tgz -P -C D:/a/zen/zen
  Cache hit, key = 'runnerOS=win2220220306.1-vcpkgGitCommit=5962cf5a3bfc21[24](https://github.com/EpicGames/zen/runs/5598118276?check_suite_focus=true#step:4:24)e8de991a4e45a8edcb3b4c69_appendedKey=release-20710ef73d32fa66a66a4fb0ed803cdce8b4099f55c53e82b7de0ec2a6fbf743'.

The reason why I’m exploring this is because my MacOS x86_64 target does not seem to use the cache properly but instead rebuilds all dependent packages taking 1-2 hours to run.

All other platforms (Linux x86_64, Windows x86_64, MacOSX arm64) uses the cache properly - even though they show the same cache hit behaviour and do not recompile the dependencies even if I change appendedCacheKey.

[lukka]

The latest version of run-vcpkg@v10 adds the prependedCacheKey input, which helps in invalidating previously created caches. It also documents how to properly handle the saving of the cache when a failure and cancellation occurs.

@DanEngelbrecht @DrMcCoy @akrieger could this issue be closed or there is something else to do on run-vcpkg side? Let me know, thanks!

[lukka]

@akrieger IIRC there is a test on the commit id to represent a SHA1 string which would prevent your idea to work, which would be neat BTW.

I think prepending the user provided key is sensible indeed, as requested as well in #160 .