"Not saving cache because no objects are cached" on Windows workflow

[alemuntoni]

I am getting the message Not saving cache because no objects are cached. on windows workflows.
I just made a small repo example to reproduce it: https://github.com/alemuntoni/ccache-hello-world)

here the workflow file and here the workflow run.

You can see that I made also similar workflows for linux and macos, which work fine.

Am I doing something wrong?

--

As @hendrikmuhs pointed on my original question on #55, ccache isn't called on my workflow:

  C:\ProgramData\Chocolatey\bin\ccache.exe -s
  cache directory                     C:\Users\runneradmin\AppData\Roaming/ccache
  primary config                      C:\Users\runneradmin\AppData\Roaming/ccache/ccache.conf
  secondary config (readonly)         R:/winlibs64_stage/inst_ccache-4.3/etc/ccache.conf
  cache hit (direct)                     0
  cache hit (preprocessed)               0
  cache miss                             0
  cache hit rate                      0.00 %
  cleanups performed                     0
  files in cache                         0
  cache size                           0.0 kB
  max cache size                       5.0 GB

Could the issue be in my cmake call?

cmake -DCMAKE_BUILD_TYPE=Release -GNinja -DCMAKE_C_COMPILER_LAUNCHER=ccache -DCMAKE_CXX_COMPILER_LAUNCHER=ccache ..
ninja

https://github.com/alemuntoni/ccache-hello-world/blob/e1f7a57576d028167218ae406ae0b04cbb881935/.github/workflows/Windows.yml#L23-L24

[jonashaag]

Your cmake command looks correct though

[jonashaag]

I think it would be good to have cmake example in the tests. If you figure out the problem feel free to submit a PR to test cmake :)

[alemuntoni]

I don't have the background to investigate and make fixes in the code unfortunately, but I did find what could be a possible cause.
It seems that the action I used to set the MSVC compiler is messing up something (I have to build with MSVC in my projects on windows).

Without setting MSVC, the ccache action works (but of course, MSVC is not set).

The action I use to set MSVC is ilammy/msvc-dev-cmd, which is the most used for this scenario. I see that ccache supports MSVC and should also this action, am I right?

[jonashaag]

Could it be that cmake skips the compiler launcher for MSVC?

[jonashaag]

Ccache recently gained Windows support so maybe your version doesn’t support it yet.

[alemuntoni]

Ccache recently gained Windows support so maybe your version doesn’t support it yet.

It seems that the ccache version that default workflows use is 4.3 (which seems that does not support msvc).
However it is not clear to me whether ccache is shipped with default github actions runners or it is installed by this action. In the latter case, maybe just installing a newer version could solve this issue!

[alemuntoni]

Update:
upgrading is not enough.
In this workflow I upgraded to ccache 4.7 (which should support msvc) before using this action.
The message error "Not saving cache because no objects are cached" persists.

[TheLastRar]

I also encountered this issue, even with updating ccache to 4.7.1 I got "Not saving cache because no objects are cached"
I was however able to get ccache working locally, so the issue seems specific to either the GitHub runners or the ccache action

I used CMake 3.25.0-rc1 locally while the runner used 3.24.2 per the runner readme
I used Ninja 1.11.1 locally, I'm unsure what version of Ninja the runners ship with
Locally I used vcvarsall.bat on actions I used ilammy/msvc-dev-cmd

Maybe one of those differences is responsible, maybe try updating Ninja like you did with ccache?

[alemuntoni]

Thanks @TheLastRar!!
It seems that it works by updating both ccache to 4.7.2 and ninja to 1.11.1 (see this action)!
I updated them using choco (choco install ccache and choco install ninja).
I don't know if these operations could be executed automatically by the ccache-action, or it would be better to wait that Github runners update ninja and ccache packages..

[hendrikmuhs]

I've updated ccache for windows to 4.7.2 and created a new release.

Let me know if that helps.

[alemuntoni]

@hendrikmuhs it seems that it is not working :(
See this job.
After using ccache-action@v1.2.4, printed version of ccache is still 4.3.

[hendrikmuhs]

Thanks @alemuntoni,

it looks like your CI image has a conflicting ccache which is taken instead of the one provided by this action. When @jonashaag added ccache for windows, the version was 4.6 afair.

From your logs: C:\ProgramData\Chocolatey\bin\ccache.exe

Chocolatey originates from the github image: https://github.com/actions/runner-images/blob/main/images/win/Windows2022-Readme.md

Unfortunately it is in the PATH before the installed one:

Path: C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\MSVC\14.33.31629\bin\HostX64\x64;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\VC\VCPackages;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TestWindow;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\bin\Roslyn;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Team Tools\Performance Tools\x64;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Team Tools\Performance Tools;C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\x64\;C:\Program Files (x86)\HTML Help Workshop;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\CommonExtensions\Microsoft\FSharp\Tools;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\Extensions\Microsoft\CodeCoverage.Console;C:\Program Files (x86)\Windows Kits\10\bin\10.0.22621.0\\x64;C:\Program Files (x86)\Windows Kits\10\bin\\x64;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\\MSBuild\Current\Bin\amd64;C:\Windows\Microsoft.NET\Framework64\v4.0.30319;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\Tools\;C:\Program Files\MongoDB\Server\5.0\bin;C:\aliyun-cli;C:\vcpkg;C:\Program Files (x86)\NSIS\;C:\tools\zstd;C:\Program Files\Mercurial\;C:\hostedtoolcache\windows\stack\2.9.1\x64;C:\cabal\bin;C:\\ghcup\bin;C:\tools\ghc-9.4.2\bin;C:\Program Files\dotnet;C:\mysql\bin;C:\Program Files\R\R-4.2.1\bin\x64;C:\SeleniumWebDrivers\GeckoDriver;C:\Program Files (x86)\sbt\bin;C:\Program Files (x86)\GitHub CLI;C:\Program Files\Git\bin;C:\Program Files (x86)\pipx_bin;C:\npm\prefix;C:\hostedtoolcache\windows\go\1.17.13\x64\bin;C:\hostedtoolcache\windows\Python\3.9.13\x64\Scripts;C:\hostedtoolcache\windows\Python\3.9.13\x64;C:\hostedtoolcache\windows\Ruby\3.0.4\x64\bin;C:\tools\kotlinc\bin;C:\hostedtoolcache\windows\Java_Temurin-Hotspot_jdk\8.0.345-1\x64\bin;C:\Program Files\ImageMagick-7.1.0-Q16-HDRI;C:\Program Files (x86)\Microsoft SDKs\Azure\CLI2\wbin;C:\ProgramData\kind;C:\Program Files\Microsoft\jdk-11.0.12.7-hotspot\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Windows\System32\OpenSSH\;C:\Program Files\dotnet\;C:\ProgramData\Chocolatey\bin;C:\Program Files\PowerShell\7\;C:\Program Files\Microsoft\Web Platform Installer\;C:\Program Files\Microsoft SQL Server\Client SDK\ODBC\170\Tools\Binn\;C:\Program Files\Microsoft SQL Server\150\Tools\Binn\;C:\Program Files\OpenSSL\bin;C:\Strawberry\c\bin;C:\Strawberry\perl\site\bin;C:\Strawberry\perl\bin;C:\ProgramData\chocolatey\lib\pulumi\tools\Pulumi\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files\CMake\bin;C:\ProgramData\chocolatey\lib\maven\apache-maven-3.8.6\bin;C:\Program Files\Microsoft Service Fabric\bin\Fabric\Fabric.Code;C:\Program Files\Microsoft SDKs\Service Fabric\Tools\ServiceFabricLocalClusterManager;C:\Program Files\nodejs\;C:\Program Files\Git\cmd;C:\Program Files\Git\mingw64\bin;C:\Program Files\Git\usr\bin;C:\Program Files\GitHub CLI\;c:\tools\php;C:\SeleniumWebDrivers\ChromeDriver\;C:\SeleniumWebDrivers\EdgeDriver\;C:\Program Files\Amazon\AWSCLIV2\;C:\Program Files\Amazon\SessionManagerPlugin\bin\;C:\Program Files\Amazon\AWSSAMCLI\bin\;C:\Program Files\Microsoft SQL Server\130\Tools\Binn\;C:\Program Files\LLVM\bin;C:\Users\runneradmin\.dotnet\tools;C:\Users\runneradmin\.cargo\bin;C:\Users\runneradmin\AppData\Local\Microsoft\WindowsApps;C:\Program Files (x86)\Microsoft Visual Studio\Installer;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\VC\Tools\Llvm\x64\bin;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\CommonExtensions\Microsoft\CMake\Ninja;C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\VC\Linux\bin\ConnectionManagerExe

You can try to fix your PATH.

For this action it would be nice if we can use full qualified paths and detect and warn if such a conflict appears.

Nice debugging! I wonder if we could somehow integrate your test project into this repo.

[alemuntoni]

Why providing a different version of ccache? Wouldn't be possible to use (and update with choco) the one that is already provided by the github image?

Could be the action ilammy/msvc-dev-cmd@v1 that is modifying PATH in such way? Consider that this action is the most used one to make MSVC compiler the default one...

Feel free to use any of the code in my test action if it is useful to setup a proper test. I don't actually know how actions work internally, therefore I am not the most suitable person to make a PR :)

[hendrikmuhs]

Why providing a different version of ccache? Wouldn't be possible to use (and update with choco) the one that is already provided by the github image?

I didn't know choco has its own and I don't know if it is meant to be used or if it is an internal tool for choco(does anyone know?). The decision to ship it with the github image is a decision of the github development team, they might change their mind. Not every project uses choco. So long story short, I don't think we should re-use it and apart from that we do not have control over the version. It seems the version isn't usable for us anyway.

I therefore think that "fixing the PATH" is the best option.

Option 3 would be renaming the binary, but this has a lot of disadvantages, e.g. w.r.t. platform compatibility, so it isn't an option IMO.

Note that I am not developing on windows at the moment, so I don't have the necessary setup to play with. At best I can take your demo-environment as playground. It would be better if someone with a stronger interest and more knowledge about tooling on windows has a look. I happily take and merge PR's.

[hasselmm]

This problem also occurs, when ccache is called and works properly. This example has 269 cached objects, consuming 17.2 MiB, but the action doesn't archive them.

Post job cleanup.
ccache stats
  C:\ProgramData\Chocolatey\bin\ccache.exe -s
  cache directory                     C:\Users\runneradmin\AppData\Roaming/ccache
  primary config                      C:\Users\runneradmin\AppData\Roaming/ccache/ccache.conf
  secondary config (readonly)         R:/winlibs64_stage/inst_ccache-4.3/etc/ccache.conf
  stats updated                       03/03/23 14:16:46
  cache hit (direct)                     0
  cache hit (preprocessed)               0
  cache miss                           135
  cache hit rate                      0.00 %
  cleanups performed                     0
  files in cache                       269
  cache size                          17.2 MB
  max cache size                       5.0 GB
Not saving cache because no objects are cached.

[sunflower-knight]

So what should we do if I want msvc+debug+ninja+ccache in window server 2022 in github workflow runner.
give a issue for github?

I can compile in this way , bug at the end of CI, it tell me no objects are cached.

[clickingbuttons]

choco upgrade ccache ninja worked for me.

Hopefully Github can upgrade their windows-latest runners with new ccache and ninja versions soon.

[JesseTG]

This issue still affects me when compiling with MSYS2 and MinGW.

[Naros]

Hi all, so I stumbled onto this issue trying to get MSVC/CL working with this CCACHE action on windows-latest workers. I found that it seemingly cached release builds without any issues:

Post job cleanup.
ccache stats
  C:\ProgramData\Chocolatey\bin\ccache.exe -s
  Cacheable calls:   10[2](https://github.com/Naros/godot-orchestrator/actions/runs/7369182839/job/20054201451#step:27:2)9 / 1029 (100.0%)
    Hits:               0 / 1029 ( 0.00%)
      Direct:           0
      Preprocessed:     0
    Misses:          1029 / 1029 (100.0%)
  Local storage:
    Cache size (GB):  0.1 /  0.5 (18.46%)
    Hits:               0 / 1029 ( 0.00%)
    Misses:          1029 / 1029 (100.0%)
Save cache using key "ccache-ccache-windows-release-202[3](https://github.com/Naros/godot-orchestrator/actions/runs/7369182839/job/20054201451#step:27:3)-12-31T07:59:31.8[4](https://github.com/Naros/godot-orchestrator/actions/runs/7369182839/job/20054201451#step:27:4)7Z".
"C:\Program Files\Git\usr\bin\tar.exe" --posix -cf cache.tzst --exclude cache.tzst -P -C D:/a/godot-orchestrator/godot-orchestrator --files-from manifest.txt --force-local --use-compress-program "zstd -T0"
Cache Size: ~83 MB (8692[5](https://github.com/Naros/godot-orchestrator/actions/runs/7369182839/job/20054201451#step:27:5)24[6](https://github.com/Naros/godot-orchestrator/actions/runs/7369182839/job/20054201451#step:27:6) B)
Cache saved successfully

But for Debug builds, it refused to cache anything:

Post job cleanup.
ccache stats
  C:\ProgramData\Chocolatey\bin\ccache.exe -s
  Cacheable calls:      0 / 10[2](https://github.com/Naros/godot-orchestrator/actions/runs/7369182839/job/20054201385#step:27:2)9 ( 0.00%)
    Hits:               0
      Direct:           0
      Preprocessed:     0
    Misses:             0
  Uncacheable calls: 1029 / 1029 (100.0%)
  Local storage:
    Cache size (GB):  0.0 /  0.[5](https://github.com/Naros/godot-orchestrator/actions/runs/7369182839/job/20054201385#step:27:5) ( 0.00%)
Not saving cache because no objects are cached.

The cmake builds are identical other than specifying debug vs release. The job insures that both ccache and ninja are the latest, of the above run the versions are:

ccache v4.8.3 is the latest version available based on your source(s).
ninja v1.11.1 is the latest version available based on your source(s).

In case this is helpful, the debug configuration is as follows:

Build Configuration
    CMAKE_SYSTEM_PROCESSOR:..................: AMD64
    CMAKE_HOST_SYSTEM_NAME:..................: Windows
    CMAKE_BUILD_TYPE:........................: Debug
    CMAKE_CXX_COMPILER_ARCHITECTURE_ID:......: x64
    CMAKE_CXX_STANDARD:......................: 20
    CMAKE_CXX_COMPILER_VERSION:..............: 19.37.32[82](https://github.com/Naros/godot-orchestrator/actions/runs/7369182839/job/20054201385#step:9:83)6.1
    CMAKE_CXX_SIZEOF_DATA_PTR:...............: 8
    CMAKE_GENERATOR:.........................: Ninja
    CMAKE_VERSION:...........................: 3.28.1
    CMAKE_MINIMUM_REQUIRED_VERSION:..........: 3.20
    VCPKG_TARGET_TRIPLET.....................: 
    CMAKE_DEBUG_POSTFIX......................: 
    GIT_COMMIT_HASH..........................: 5fea906d5a63a659524513b7304ddd627da6a5b0

CMake Paths
    CMAKE_CURRENT_SOURCE_DIR.................: D:/a/godot-orchestrator/godot-orchestrator
    CMAKE_TOOLCHAIN_FILE:....................: 
    CMAKE_SOURCE_DIR:........................: D:/a/godot-orchestrator/godot-orchestrator
    CMAKE_COMMAND:...........................: C:/hostedtoolcache/windows/cmake/3.28.1/x64/cmake-3.28.1-windows-x[86](https://github.com/Naros/godot-orchestrator/actions/runs/7369182839/job/20054201385#step:9:87)_64/bin/cmake.exe
    CLANG_FORMAT_PROGRAM:....................: 
    SCONS_PROGRAM:...........................: C:/hostedtoolcache/windows/Python/3.12.1/x64/Scripts/scons.exe
    CMAKE_CXX_COMPILER:......................: C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.37.32822/bin/HostX64/x64/cl.exe
    CMAKE_LINKER:............................: C:/Program Files/Microsoft Visual Studio/2022/Enterprise/VC/Tools/MSVC/14.37.32822/bin/HostX64/x64/link.exe
    CMAKE_BUILD_TOOL:........................: C:/ProgramData/chocolatey/bin/ninja.exe
    vcpkg_executable:........................: 
    godot_debug_editor_executable:...........: D:/a/godot-orchestrator/godot-orchestrator/extern/godot-engine/bin/godot.windows.editor.dev.x86_64.exe
    CMAKE_INSTALL_PREFIX:....................: C:/Program Files (x86)/orchestrator
    CMAKE_BINARY_DIR:........................: D:/a/godot-orchestrator/godot-orchestrator/.out-windows-debug
    GDEXTENSION_LIB_PATH:....................: D:/a/godot-orchestrator/godot-orchestrator/project/addons/orchestrator

Any ideas or suggestions on what could be the problem?

[pwiecz]

@Naros in my case the debug information format was making the compilation calls uncacheable.

In recent cmake version you can try setting CMAKE_MSVC_DEBUG_INFORMATION_FORMAT=Embedded and see if it helps.

In slightly older version you would need:

string(REPLACE "/Zi" "/Z7" CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG}")
string(REPLACE "/Zi" "/Z7" CMAKE_C_FLAGS_RELWITHDEBINFO "${CMAKE_C_FLAGS_RELWITHDEBINFO}")
string(REPLACE "/Zi" "/Z7" CMAKE_CXX_FLAGS_RELWITHDEBINFO "${CMAKE_CXX_FLAGS_RELWITHDEBINFO}")```

[Naros]

Hi @pwiecz I tried both solutions and neither seemed to work for debug builds.

[pwiecz]

@Naros I guess you'll have to try to determine why the compilations were uncacheable in your case by increasing verbosity and looking into ccache logs.
For that you may have to build the project locally to have access to ccache logs.

Unfortunately, I cannot recall right now how exactly I was debugging my own case... :(