Improve docs regarding cache key matching

[dabrahams]

I keep having the experience that the restore step fails even when caches with the right key clearly exist. I don't know how to explain when the key lookup is successful.

[dabrahams]

Some or all of this effect may come down to branch-scoping, which I only just discovered. Since this action's docs (rightly) don't say “go read everything about actions/cache on which it is based,” it might be a good idea to mention this in the README.

[hendrikmuhs]

Are you fine with changing the title to: "Improve docs regarding cache key matching"?

Note that you have to see it from a security perspective as well: You don't want a PR/feature branch to be able to "infect" the main branch cache. LBNL caching itself is just a way to speed up things if possible, there is no guarantee on hitting.

FWIW: Feel free to create a PR with improvements on the README.

[dabrahams]

Feel free to create a PR with improvements on the README.

At the time of my posting, I didn't understand how cacheing works well enough to even take a shot at it. Now I understand what GH does (I think), but not necessarily what this plugin adds to the picture. Until I have that info I wouldn't know what to write.

[Rotonen]

With organizations using merge queues, the branch scoping makes it quite tricky to have the merge queues benefit from the caching.