I have another cache related question :thread:
# general
c
I have another cache related question đŸ§”
I have observed this message in a post step from a GH action workflow:
Cache hit occurred on the primary key pants-named-caches-Linux-v0-d154b8007fde31179adbd61ffe987a6179fd9906aef8530cef6380a2d4675a42-9466e26d26c07b231d49f6425a26b4e6e88d5b39ca936e191991d98ee6c4e127, not saving cache.
Now, this seems to me that the cache entry will hold what ever was put into that first run when this cache blob was first created. But, what if that was for a run that using
--changed-since
didn’t fetch everything, and it seems the cache is not subsequently updated after that.. how do we ensure we get a “good” cache blob?
my idea now leans towards that we need to touch the lockfiles in order to run “all” the tests, and that should be close to “good” in that sense. So here’s a gotcha that if you make changes or touch the “gha-cache-key” in order to “bust the caches” you may get a really small cache blob that is practically useless. (I went from 3G to 12M
which wasn’t what I was looking for) 😛
b
Your observation is correct, for GHAs default caching action. I think the only way to reliably get good caches when caching coarsely with it is to avoid —changed-since
 or to capture the changes in the cache key itself. It looks like there’s now the possibility to explicitly save a cache, which might allow overwriting, but the docs aren’t exactly encouraging: https://github.com/actions/cache#using-a-combination-of-restore-and-save-actions
c
thanks for confirming. also having changed since in the cache key feels like it would be a bit chicken-and-egg problem (or resolve to using bare
git
..)
and thanks for the nudge about cache/save, good to know about
b
Another option would be only using changed-since if the cache action reports a hit, and doing a “full” build if not. That said, depending on the “real” caching, processes may not actually run to fill out the named caches, even without the changed-since filtering?