Cache issue on macOS hosted runner

I am caching my build directory generated with CMake. Each time Github update the runner (here from 2.262.1 to 2.263.0), the compilation fails:

CMake Error: The current CMakeCache.txt directory /Users/runner/runners/2.263.0/work/OpenGeode/OpenGeode/build/third_party/spdlog/src/spdlog-build/CMakeCache.txt is different than the directory /Users/runner/runners/2.262.1/work/OpenGeode/OpenGeode/build/third_party/spdlog/src/spdlog-build where CMakeCache.txt was created. This may result in binaries being created in the wrong place. If you are not sure, reedit the CMakeCache.txt

The main issue is that the version number is inside the path. Is there a way to avoid that behavior or to clean the cache manually?

Thanks for your help

@botellaa,
You are using a hardcode string to set the directory of the generated build in your workflow, right?

The directory “/Users/runner/runners//work//” actually is the workspace directory for each workflow run on the macOS runner machine. You can easy use the “github.workspace” property of the github context or the default environment variableGITHUB_WORKSPACE” to access the directory in the workflow.

So, you should use “github.workspace” or “GITHUB_WORKSPACE” in your workflow, instead of a hardcode string. In this way, you do not need to changes the directory every time the runner version is changed, the latest directory will automatically be mapped to the github context and the default environment variable every time the workflow is triggered to run.
For example:

cache_file_path=${{ github.workspace }}/build/third_party/spdlog/src/spdlog-build/CMakeCache.txt 

OR

cache_file_path=$GITHUB_WORKSPACE/build/third_party/spdlog/src/spdlog-build/CMakeCache.txt 

I am not directly using hard coded string but CMake does and I cannot control this.
I am caching using the workspace variable as you suggest but one of the file generated by CMake still have hard coded information.

@botellaa,
If you can edit the configure/settings file for CMake in your project, maybe you can try to using relative paths to the workspace to place and access the generated build files, instead of absolute paths. And you can combine the workspace directory with the relative paths to get the absolute paths of the files (as the examples I posted above).

I think this should be the most ideal solution to solve the problems you are facing.