My packages use Github Actions for CI/CD, and like most people, leverage the excellent set of actions developed by @jimhester and others.
Recently I ran into a problem where a build was failing due to installing the incorrect version of a package dependency. After some digging, it was found that this is because the cached package was out of date, and although the cache key
${{ runner.os }}-${{ hashFiles('.github/R-version') }}-2-${{ hashFiles('.github/depends.Rds') }}
picks this up, the restore key
${{ runner.os }}-${{ hashFiles('.github/R-version') }}-2-
doesn't. Because of this, GHA merrily continues using the existing cache, breaking the pipeline downstream.
Note that these are basically the same keys as defined in the r-lib/actions repo -- I haven't changed them except to bump 1
to 2
.
This weekend I've done a bit more work on the package, and updated the dependencies as well. Naturally, the build broke again because of the cache miss. The solution from last time still works: change the cache keys to manually invalidate the cache, and thus force it to be rebuilt.
This is kind of annoying; I don't want to have to change the cache keys every time I update my package dependencies. Instead, I'd like GHA to detect that the cache is invalid and rebuild it automatically when this happens. This was the default behaviour when I was using Azure Pipelines, for instance.
2 questions:
- If I change the
restore-keys
value to matchcache-keys
, will it give me the behaviour I'm after? - What is the reason that
restore-keys
is different tocache-keys
?