Wrong cache directory

according to: https://github.com/lukka/run-vcpkg/blob/d950c946406d5336fc77433f256c813b94f330d9/src/vcpkg-action.ts#L102

it’s save a wrong cache (from vcpkg docs):

Currently, our file-based backend is enabled by passing the undocumented --binarycaching flag to any 
Vcpkg command or setting the undocumented environment variable VCPKG_FEATURE_FLAGS to binarycaching. 

We will replace this feature flag with an on-by-default user-wide behavior, plus command line and environment-based configurability.

The on-by-default configuration will specify the file-based archive protocol on either 
%LOCALAPPDATA%/vcpkg/archives (Windows) or $XDG_CACHE_HOME/vcpkg/archives (Unix). 
If XDG_CACHE_HOME is not defined on Unix, we will fall back to $HOME/.cache/vcpkg/archives based 
on the XDG Base Directory Specification. 
This can be redirected with a symlink, or completely overridden with the command line or environment. 
In the future we can also consider having a user-wide configuration file, 
however we do not believe this is important for any of our key scenarios.

https://vcpkg.readthedocs.io/en/latest/specifications/binarycaching/#solution-aspects

for example with your actions every run it’s what happens:

  Could not locate cached archive: /home/runner/.cache/vcpkg/archives/b0/b0c723932ac57ff82b8bb08dad40b2b9c5ed146d.zip

  Stored binary cache: /home/runner/.cache/vcpkg/archives/b0/b0c723932ac57ff82b8bb08dad40b2b9c5ed146d.zip

Caching paths: '/home/runner/work/atomicDEX-Desktop/atomicDEX-Desktop/ci_tools_atomic_dex/vcpkg-repo,!/home/runner/work/atomicDEX-Desktop/atomicDEX-Desktop/ci_tools_atomic_dex/vcpkg-repo/packages,!/home/runner/work/atomicDEX-Desktop/atomicDEX-Desktop/ci_tools_atomic_dex/vcpkg-repo/buildtrees,!/home/runner/work/atomicDEX-Desktop/atomicDEX-Desktop/ci_tools_atomic_dex/vcpkg-repo/downloads'
  Running save-cache
  /usr/local/bin/tar --use-compress-program zstd -T0 -cf cache.tzst -P -C /home/runner/work/atomicDEX-Desktop/atomicDEX-Desktop --files-from manifest.txt
  Cache saved successfully

^ we can see that $HOME/.cache/vcpkg/archives or C:\Users\runneradmin\AppData\Local\vcpkg\archives\ is missing in the caching path

would be nice to have a v6 that cache the good directory

I never made typescript in my life but an equivalent in c++ would be :

std::vector<std::filesystem::path> get_cache_paths() 
{
     std::vector<std::filesystem::path> paths;
#if defined(_WIN32) || defined(WIN32)
        const char* localappdata = nullptr;
        
        if (localappdata = std::getenv("LOCALAPPDATA"); localappdata)
        {
              paths.push_back(std::filesystem::path(localappdata) / "vcpkg" / "archives");
        }
#else
       const char* home = nullptr;
       
        if (home = std::getenv("XDG_CACHE_HOME"); home)
        {
              paths.push_back(std::filesystem::path(home) / "vcpkg" / "archives");
        } else if (home = std::getenv("HOME"); home) {
              paths.push_back(std::filesystem::path(home) / ".cache" / "vcpkg" / "archives");
        }
#endif
   return paths;
}

[ras0219-msft]

In the cache hit scenario, that’s the correct TL;DR – as long as every package is in the installed\ folder, we won’t consult the archives. The only way a package would be missing from the installed folder is if the cache didn’t hit, in which case the archives would also be missing. There is potentially some improvement available via fallback keys on the archives directory, however I think this is relatively low value.

Instead, we recommend using GitHub Packages[1] to store the binaries via our NuGet backend. This will reuse packages as much as possible and complement the Cache Task to maximize performance and minimize rebuilds.

[1] https://github.com/microsoft/vcpkg/blob/master/docs/users/binarycaching.md#github-packages

[lukka]

Please review the following and let me know if you are on the same page.

TL;DR There is no reason to cache the binary cache directory content on the GitHub cache service, as it will just increase the restore from cache scenario. Continuing caching the $VCPKG_ROOT directory is the most performant solution.

Details Please remember that run-vcpkg puts into the GitHub cache service basically all of $VCPKG_ROOT (excluding some directories to dramatically reduce the required space). So when the action installs sqlite3 package and the package has been restored from the GitHub cache, it takes <0.1 second.

OTOH, if run-vcpkg is changed to do as requested here, installing sqlite3 (i.e. vcpkg install sqlite3) with the $VCPKG_ROOT/installed directory empty, it would take >3 seconds. The times looks like spent mostly in detecting the “compiler hash for triplet…” (longer on Windows than on Linux, but in both cases it’s >1 second), and expanding the archive and writing the new files onto $VCPKG_ROOT/installed directory.