Cache: Cache not being hit despite of being present

[BrightRan]

In this ticket, the user use the cache action to cache some dependencies. At the first time to run this action in the workflow , it will returns that Cache not found for input keys, and then the cache will be saved with the specified key in the Post cache step, this is correct behavior as expected.
However, when run the action next time, it still reports that Cache not found for input keys, the key is same as the first time.

I tested and tried as the demo shared by this user, but I did not reproduce the problem.

[RJ722]

Hi, thanks @BrightRan for opening the issue.

It was me who opened the ticket.

I have some more info to add:

I tried changing the path to path: /home/runner/.cache/pypoetry/virtualenvs (instead of ~/.cache/pypoetry/virtualenvs in apprehension that ~/ might lead to another home directory) -- which seemed to have worked (at least for a while). The subsequent 2 builds could access this cache.

However, when I tried creating a new branch and raising a PR from that, cache started missing again. I can't pin point if this is a problem with my configuration, or a bug because of the random nature of it. Is there a way I can debug this (additional logs, etc.)? Thanks!

[joshmgross]

Could you provide examples of your workflow?

Cache's are scoped to a key and a branch, so a cache created on branch-A won't be accessible by branch-B unless branch-A is the default branch.

See https://help.github.com/en/actions/configuring-and-managing-workflows/caching-dependencies-to-speed-up-workflows#matching-a-cache-key for more info.

It's recommended that you have a workflow run on your default branch (usually master) so that worklows on other branches will have a cache to restore from.

[BrightRan]

A new ticket is reporting the same problem: https://github.community/t5/GitHub-Actions/Using-the-cache-action-for-node-modules/td-p/51603

[mandolyte]

@BrightRan Thanks for directing me to this issue. I can confirm the problem and I have details written up over here:
https://github.community/t5/GitHub-Actions/Using-the-cache-action-for-node-modules/m-p/51816#M8312

My workflow is here:
https://github.com/unfoldingWord/book-package-app/tree/master/.github/workflows

Other notes:

• I only use the master branch (there is a gh-pages branch, but I don't directly use it of course)
• My code (a React Web App) hasn't changed in some time. My workflow is about converting that code base to Electron so it can run as a standalone app. I wanted to cache the ./node_modules directory. This directory of course is in .gitignore, so it isn't present on checkout.

I'll keep the cache action in the workflow and hope that it will just start working at some point. Otherwise the workflow is working and I don't plan to continue working on it until next round of bugs/enhancements need attention.

[dhadka]

@mandolyte The behavior you're seeing is possibly related to what is discussed in this issue: https://github.com/actions/cache/issues/149

For push events, the cache action can write and read from caches created for the current ref, and it can also fall back to reading from the cache from the default/master branch.

In your workflow, since you only trigger off pushing new tags, every cache is created for that new, unique tag ref. Since you don't have push triggers off of master, no cache is ever restored.

Caching is ideal when you have frequent builds on your default branch, as that results in close matches for new branches and tags.

[mandolyte]

If this is expected behavior, then I'll remove the cache action from my workflow.

[mandolyte]

Before I entirely leave this issue, I ask that consideration be given to altering this "expected behavior". Given that any use of caching for JS/TS project will always be followed by an update (such as yarn install) in order to ensure that any changes in package.json are brought in, then adding scopes for branches/tags severely limits the usefulness of caching. As stated in the quote above, its sole use case is for "frequent builds on your default branch". But as I reasoned here, it could be useful beyond that. Cheers!

[RJ722]

Hello, and apologies for the late reply @joshmgross. I wasn't aware of the scoping of the builds across different branches. If that's expected behavior, we are working fine!

However, I'd still like to request you to make this point a little more prominent in the docs/README.

Thanks for your reply!

[joshmgross]

307 has added this detail to the main README with a link to the help docs for more details.

Thank you all for the feedback!