Conversation
This is useful for rebuilding caches. The current cache restore fallback logic leads to saving only one Github cache for each cache type and never updating it. Over time caches and code start to drift, which requires refreshing caches. With `skip-cache-restore` they can be refreshed if needed.
The content of the repository cache can be influenced by more than MODULE.bazel or the WORKSPACE files. E.g. .bazelversion or files included by MODULE.bazel can either define the version of dependencies or pull in more. As these will eventually land in the lockfile add it to the hash to have different hash values on changes of pulled in dependencies.
|
FYI I wondered if it makes sense to treat the repository and disk cache individually, but decided against that. If you think this is useful I can change the code. |
|
Sorry, I missed this PR! Whenever I need to bust the cache, I normally would bump the |
|
Never mind. To keep the behavior I currently have with My first attempt would be to use I can try if that works, but I cannot promise that I will come back quickly, because I currently have a working solution with the code of this PR and there is at the moment no pressure to change it. |
Not quite, since github cache beyond 10GB costs money we are working on solutions how to evict caches as soon as possible. And since we run this on 100+ repos we dont want to do anything manually. |
3 participants
This is useful for rebuilding caches. The current cache restore fallback logic leads to saving only one Github cache for each cache type and never updating it. Over time caches and code start to drift, which requires refreshing caches. With
skip-cache-restorethey can be refreshed if needed.Because the repository cache can also change by e.g. changes in
.bazelversion, add the lockfile to avoid hash collisions. Otherwise writing a new cache might fail, even if its content differs.