Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Cache misses due to path-based versioning and its normalization

See original GitHub issue

This run using actions/cache@v2 shows how a cache created by the update-deps job is not hit by the jobs in the test matrix that depend on update-deps and use the same key. This works in actions/cache@v1, so it looks like a regression to me.

What’s more peculiar, each of the three test jobs reported to have successfully stored its cache state under this same key. In the next run, all jobs hit the cache, but which state did they get?

Issue Analytics

State:
Created 3 years ago
Comments:17 (8 by maintainers)

Top GitHub Comments

1reaction

Phantsurecommented, Dec 7, 2022

@mzabaluev @y-nk We have released a new beta release which should fix this issue. Try tag: actions/cache@3.1.0-beta. Head over to discussion for feedback: https://github.com/actions/cache/discussions/1019

1reaction

mzabaluevcommented, Jun 2, 2020

The version hash includes the compression method, but we fall back to using Gzip instead of Zstd on Windows due to bug #301.

I hope in the end state it would be possible to share cache state no matter which runner created it, with the restore action being able to adapt to a possibly different archival format; or maybe this and other tar-related issues will be solved by settling on a single flavor of tar that works across all OSes. The disparate cache entries for Windows and Unix would increase our cache pressure twofold and duplicate the dependency fetching work for Windows jobs without a good reason for it.