GitHub binary cache not stored (insufficient error message?)

[albertziegenhagel]

I am trying to use the new binary caching using GitHub actions cache (x-gha). It mostly works as expected, but for LLVM on Windows I do just see

Stored binaries in 0 destinations.

without any further explanation why the binaries have not been stored. When running with --debug I get

...
[DEBUG] CreateProcessW(curl -s -H "Content-Type: application/json" -H "Authorization: ***" -H "Accept: application/json;api-version=6.0-preview.1" https://artifactcache.actions.githubusercontent.com/oSimyly2ZhF4WDxuY33bHvrJQQIlAP70N3UB2VQdWbVKMWPP1q/_apis/artifactcache/caches -d "{
  \"key\": \"vcpkg\",
  \"version\": \"8ae11dc2ba02e8d280190fc93f6c4ae252f90b634a1fbf6fc1bc37e44e53b1a6\",
  \"cacheSize\": 636612428
}
")
[DEBUG] ReadFile() finished with GetLastError(): 109
[DEBUG] 1032: cmd_execute_and_stream_data() returned 0 after   134566 us
Stored binaries in 0 destinations.

so it seems that it stops after trying to reserve the cache entry. My guess is that GitHub rejects the cache because it is to big?! But it is hard to tell, because there is no error message generated.

From reading the vcpkg-tool source, I would guess that it stops at
https://github.com/microsoft/vcpkg-tool/blob/b709fcce3734beddd0d0d75289443ca09e2a04a1/src/vcpkg/binarycaching.cpp#L1025
and then the if at
https://github.com/microsoft/vcpkg-tool/blob/b709fcce3734beddd0d0d75289443ca09e2a04a1/src/vcpkg/binarycaching.cpp#L1130
does not have an else and hence no meaningful error is generated.

I would suggest to at least create a debug message with the response from the GitHub API call when no cacheId could be found in the response. My guess is that GitHub will actually send a meaningful error here.

If more information on the actual failure case is needed, the complete GitHub action workflow log can be found here:
https://github.com/albertziegenhagel/snail-server/actions/runs/4778662169/jobs/8495225986#step:8:1120

[FrankXie05]

I think it may be caused by permission problems or network problems.

so it seems that it stops after trying to reserve the cache entry. My guess is that GitHub rejects the cache because it is to big?! But it is hard to tell, because there is no error message generated.

  \"key\": \"vcpkg\",
  \"version\": \"8ae11dc2ba02e8d280190fc93f6c4ae252f90b634a1fbf6fc1bc37e44e53b1a6\",
  \"cacheSize\": 636612428

606Mb is too small for llvm.

If it can be verified that it is due to the cache_size , then we are indeed missing some error prompts.

[albertziegenhagel]

I think it may be caused by permission problems or network problems.

Could be the case as well. Though I don't think it is a permission problem, since all other ports in the same workflow got stored successfully. That's why I think the error message would be helpful: it should tell us why GitHub actually rejected the cache.

606Mb is too small for llvm.

Please note that I am building the release version only (using the community triplet x64-windows-static-release) and I disabled all optional features (basically installing llvm[core,default-options]) . ~600MB for the zip-compressed packages folder is what I get locally as well.

If it can be verified that it is due to the cache_size , then we are indeed missing some error prompts.

I would hope that printing the response of the cache reservation API call in the case that it does not include the cacheId entry, would either verify that or give us the real reason why it failed. What do you think?

[quyykk]

It's not the cache reservation, but rather GitHub rejecting uploads bigger than something like 500MB. The solution is to split the upload into chunks, just like the official actions/cache action. I'll fix it, thanks for reporting! 😄

[dg0yt]

Note that vcpkg CI has the same problem with AZP.

[github-actions]

This is an automated message. Per our repo policy, stale issues get closed if there has been no activity in the past 180 days. The issue will be automatically closed in 14 days. If you wish to keep this issue open, please add a new comment.