ci: Add vcpkg tools cache #23215

On master (02feae54a53ff654f7cecf17ed467edcd612cd0c) vcpkg downloads some tools that are used internally:

...
  A suitable version of cmake was not found (required v3.20.0). Downloading portable cmake v3.20.0...
  Downloading cmake...
    https://github.com/Kitware/CMake/releases/download/v3.20.2/cmake-3.20.2-windows-i386.zip -> C:\Users\ContainerAdministrator\AppData\Local\Temp\vcpkg\downloads\cmake-3.20.2-windows-i386.zip
  Extracting cmake...
  A suitable version of 7zip was not found (required v18.1.0). Downloading portable 7zip v18.1.0...
  Downloading 7zip...
    https://www.nuget.org/api/v2/package/7-Zip.CommandLine/18.1.0 -> C:\Users\ContainerAdministrator\AppData\Local\Temp\vcpkg\downloads\7-zip.commandline.18.1.0.nupkg
  Extracting 7zip...
  A suitable version of nuget was not found (required v5.5.0). Downloading portable nuget v5.5.0...
  Downloading nuget...
    https://dist.nuget.org/win-x86-commandline/v5.5.1/nuget.exe -> C:\Users\ContainerAdministrator\AppData\Local\Temp\vcpkg\downloads\22ea847d-nuget.exe
  Detecting compiler hash for triplet x64-windows-static...
  A suitable version of powershell-core was not found (required v7.1.0). Downloading portable powershell-core v7.1.0...
  Downloading powershell-core...
    https://github.com/PowerShell/PowerShell/releases/download/v7.1.3/PowerShell-7.1.3-win-x86.zip -> C:\Users\ContainerAdministrator\AppData\Local\Temp\vcpkg\downloads\PowerShell-7.1.3-win-x86.zip
  Extracting powershell-core...
...

If any of downloads above fails the whole CI task fails (see #23107). The most recent failure examples in the master branch:

• https://github.com/bitcoin/bitcoin/commit/c001da306b29c46ef1e7421002c3aba3ff5ed514, log
• https://github.com/bitcoin/bitcoin/commit/12ff8993bcc7315f4a9b69bf16def980bb0e5197, log

This PR adds vcpkg tools cache.

Closes #23107.

Note for reviewers. Some patches from the initial PR were split into separated PRs: #23310 and #23329. Therefore, a discussion here could be outdated or irrelevant until the recent push.

The size of the vcpkg downloads cache will be lesser significantly after bumping vcpkg up to https://github.com/microsoft/vcpkg/commit/0fd101a2c5c6a5b47cef35e172be0ae32dd241d4 or later.

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--174a7506f384e20aa4161008e828411d-->

Conflicts

No conflicts as of last run.

cc @MarcoFalke

Concept ACK, but I am not familiar with vcpkg

cc @sipsorcery

I think I mentioned it on the original PR that moved the Windows build to Cirrus but we did have a period of instability that was caused by caching vcpkg dependencies #19431 and #19444. Just thought I'd mention it in case the same issue crops up again and is traced back to this PR.

Other than that vcpkg has a new'ish binary caching feature which is recommended for CI use. If vcpkg dependencies are going to be cached again it would seem to make sense to enable it. By only caching the C:\Users\ContainerAdministrator\AppData\Local\vcpkg\archives directory, without the feature, it could cause the ABI mismatch between the dependencies and the compiler version we encountered in the past. In theory all that should be required is to set the environment variable to:

VCPKG_FEATURE_FLAGS: 'manifests,binarycaching'

@sipsorcery

I think I mentioned it on the original PR that moved the Windows build to Cirrus but we did have a period of instability that was caused by caching vcpkg dependencies #19431 and #19444. Just thought I'd mention it in case the same issue crops up again and is traced back to this PR.

Other than that vcpkg has a new'ish binary caching feature which is recommended for CI use. If vcpkg dependencies are going to be cached again it would seem to make sense to enable it. By only caching the C:\Users\ContainerAdministrator\AppData\Local\vcpkg\archives directory, without the feature, it could cause the ABI mismatch between the dependencies and the compiler version we encountered in the past. In theory all that should be required is to set the environment variable to:

VCPKG_FEATURE_FLAGS: 'manifests,binarycaching'

Sorry, I didn't get your point.

• Binary Caching

We already use binary caching. This PR does not introduce it. It rather makes sure that the cache will be re-populated when vcpkg version is bumped. Maybe also it's reasonable to invalidate the cache when msbuild -version is changed?

Btw, the "Binary Caching" feature is enabled by default now (as the "Manifest Mode" feature as well), and no need to pass binarycaching to the VCPKG_FEATURE_FLAGS variable.

• Downloads Caching

This PR introduces new cache which is not an internal vcpkg feature, but rather a CI's one. These downloads actually are internal vcpkg dependencies, not ours.

We already use binary caching.

I don't think so, at least the old appveyor job wasn't. I had it enabled on my personal appveyor job to save 10 minutes on the Bitcoin Core build but I'm pretty sure it was never turned on for the main Bitcoin Core CI job.

Maybe also it's reasonable to invalidate the cache when msbuild -version is changed?

I think that's very desireable due to the aforementioned ABI incompatabilites that crop up. It's been my experience that vcpkg, with binary caching enabled, rebuilds dependencies if it detects an updated compiler.

Btw, the "Binary Caching" feature is enabled by default

That's good news, I hadn't spotted that. The CI config in this PR is still pegging vcpkg to commit ID 75522bb1f2e7d863078bcd06322348f053a9e33f so won't be taking advantage of the new defaults.

An alternative to my suggestion of explicitly setting binary caching on, would be to update the vcpkg commit ID to 5568f110b509a9fd90711978a7cb76bae75bb092 which is the latest 2021.05.12 release and looks like it would have manifests and binary caching enabled by default.

I don't think so, at least the old appveyor job wasn't. I had it enabled on my personal appveyor job to save 10 minutes on the Bitcoin Core build but I'm pretty sure it was never turned on for the main Bitcoin Core CI job.

On Cirrus CI Windows job it is enabled: https://github.com/bitcoin/bitcoin/blob/986003aff93c099c400c9285b4a2ed63f4b3f180/.cirrus.yml#L124-L125

where the default location is used :tiger2:

On Cirrus CI Windows job it is enabled

I'm not sure just caching the vcpkg download directories is enough.... It's the libraries that are built from the downloaded source archives that are used in the Bitcoin Core build. How those libraries are detected as out of date is the question.

Is there any reason not to bump the vcpkg commit to 75522bb1f2e7d863078bcd06322348f053a9e33f?

Now that you've pointed out manifests and binary caching are enabled by default it seems like a good idea to take advantage of them. And it would make our discussion academic :).

@sipsorcery

An alternative to my suggestion of explicitly setting binary caching on, would be to update the vcpkg commit ID to 5568f110b509a9fd90711978a7cb76bae75bb092 which is the latest 2021.05.12 release and looks like it would have manifests and binary caching enabled by default.

Thanks! Done in #23310.

Converting this PR into a draft for now.

Rebased and reworked on top of #23310 and #23329 -- 7132a2b7c20ca6a403cb95db53a403b5351cc52f -> f778845d972578e7abdced64ec6129d809c816f6 (pr23215.01 -> pr23215.02).

PR description updated.

@sipsorcery

Do you mind having another look at this PR?

Makes sense to me.

ACK f778845d972578e7abdced64ec6129d809c816f6.