Github Action: how to automatically rebuild the cache if it becomes invalid?

[Hong]

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:

1. If I change the restore-keys value to match cache-keys, will it give me the behaviour I'm after?
2. What is the reason that restore-keys is different to cache-keys?

[jimhester]

If you don't want the fallback behavior you can remove the restore-keys entry entirely.

The behavior you describe, falling back to the previous cache is the intended behavior. Generally this works well automatically because the cache only contains older versions of packages, and remotes or pak both will automatically upgrade packages.

However if your cache contains a newer version of a dependency you will have to bump the version number of the cache.

As I said if you don't want this behavior the best option is to remove the restore-keys field entirely.

[Hong]

Thanks @jimhester.

I'm not sure I understand. I can see that the current setup works well in the situation where dependencies get updated, eg I import package foo and it gets updated on CRAN from version X.0 to X.1. But if I change my dependencies, eg if I add package bar to imports/depends, or I add foo (>= X.1), then the cache breaks.

Will removing the restore-keys fix this behaviour? What is the downside -- I guess it means any time a (recursive) dependency is updated on CRAN, the entire cache is rebuilt?