False-positive cache hits #115
Comments
|
@Shatur the cache hit occurred on the primary key, that is the reason is not created again, as it was already created in the past. vcpkg is rebuilding everything because of this: Questions:
|
I assume this one: log.txt |
|
|
@Shatur thanks for providing the data! So far this is the description of the problem:
and the whole content of the
The size is 1GB, and it is not empty, and the key matches the one in the workflow run that created the cache. Next stepBy all of the above, looks like vcpkg is refusing to use the cached binary packages stored under Next steps:
|
|
Thanks for looking into it?
How can I do this? |
One way is to create a workflow that is running - name: discover why vcpkg does not consume the binary archives
run: $VCPKG_ROOT/vcpkg install --debug
shell: bash ; or whatever it is needed, e.g., pwsh
working-directory: ${{ env.VCPKG_ROOT }} |
Here is the output: log.txt |
|
@Shatur I think that, when launching vcpkg, the triplet must be explicitly passed in also, since the default is run: $VCPKG_ROOT/vcpkg install --debug --triplet x64-windows |
|
Right, here is with the correct triplet: log.txt |
|
@Shatur thanks a lot for the logs with
|
Here is what I tried.
Let me try it. |
The issue doesn't exists after changing the |
|
@Shatur i wonder if you hit some sort of special case where the image OS of the GitHub runners changed between the time the cache has been created, and the time it is being consumed, and that would cause But I do not have any info about where the cache is being consistently discarded, do you have such information? I see that the last stable release of the runners for Windows 2019 is the more recent |
Yes, runs with cache misses use other versions: Maybe we should include compiler version into cache keys? |
|
@Shatur that would be good, but I do not know how to get the version of the compiler used by |
|
I think I understand why this is happening. If I cancel the task or it fails on a new hash, then the cache is saved, but only partially (because the job was cancelled or failed). And on all next executions with the same hash only this cache part will be restored. |
|
@Shatur that is a correct observation indeed. Looks like there is no logic to handle the case where the Do you have a link (or log file with verbose mode on) of a cancelled workflow? This case should be accounted and working correctly, since |
Right now I don't have a verbose-enabled log, but this is the case. I observed this issue just now. |
|
@Shatur a link to the run, or the non-verbose log could be still something to be look into. |
|
@Shatur thanks for the logs! The status of the workflow is not properly read in the post action of A way to read the job status from the post action is needed to solve this problem, and the documentation does not provide one. |
Is it possible to run post actions only success? As we can do with regular actions using |
|
@Shatur the post-action has the condition |
Oh, makes sense. |
|
@Shatur I tried to get the status of the currently running job in the post action by using REST APIs, and unfortunately my conclusion is that it is not possible to get the status of a running job, but only of a job already completed. Otehrwise the only option I see is to drop the
|
But what if the job fails at CMake configuration step as in my case? |
|
@Shatur it will save broken cache indeed, but that is not avoidable, unless we devise something. |
|
Will try, but I don't think it will help since the issue in non-full cache creation :( |
|
@Shatur note you can use the I am pretty sure we can find a way to embed this logic into the action itself in the future. |
Hm... I think I can try to set this var on a separate step using |
Hi! I experiencing false-positive cache hits. I use manifest mode and vcpkg is downloaded with this action.
Action log
Configuration step log (I omitted most of it, but all packages are rebuilt).
Action post step
Is prints
Saving cache is skippedwhich shouldn't be the case.My CMake command:
cmake -B build -G Ninja -D CMAKE_BUILD_TYPE=Release -D CMAKE_TOOLCHAIN_FILE=$env:VCPKG_ROOT/scripts/buildsystems/vcpkg.cmake -D VCPKG_TARGET_TRIPLET=x64-windows -D VCPKG_INSTALL_OPTIONS=--clean-after-buildThe text was updated successfully, but these errors were encountered: