I've noticed that in one of my private repos, the cache is never hit even though the cache is small and at the end of each run it says it successfully saved.
Cache not found for input keys: Linux-eslint-e2e650427648991b0a4acaf9d0a8af37ce90a05d, Linux-eslint-.
Post job cleanup.
/bin/tar -cz -f /home/runner/work/_temp/random-hash/cache.tgz -C /home/runner/work/myproject/myproject/.cache/eslint .
Cache saved successfully
Here's the workflow step:
- name: cache eslint
uses: actions/cache@v1
with:
path: ./.cache/eslint
key: ${{ runner.os }}-eslint-${{ github.sha }}
restore-keys: |
${{ runner.os }}-eslint-
Are there any reasons for this? I'm assuming caching isn't supported in free-tier private repos yet but I haven't seen that anywhere in the documentation.
Hey @jahed,
I'd expect it to work on all repositories, so I don't think that would be an issue.
It might be helpful to turn on debug logging, see https://help.github.com/en/actions/automating-your-workflow-with-github-actions/managing-a-workflow-run#enabling-step-debug-logging
And if you want me to look at our internal logging to see what's going on, feel free to message me your repository name ([email protected]) or post it in this thread.
You may also want to try changing your path, I'm not sure if the ./ is required.
I'll see if I can get anywhere with the debug logs and path change.
Changing the path didn't do anything. With debug logging enabled there's not really much to see. There's a 204 and it misses the cache. On the other end there's a 200 and reports success.
This is a good chance for me to learn how to debug actions since my deployment pipeline relies on it. :worried:
I'm guessing this repo can be forked and my workflow can switch over to the fork for additional debug logging.
I'll update if I get anywhere (it's the weekend so probably next week).
I've figured it out after hours. :tired_face:
For some reason, actions/cache does not like hidden directories being cached. That is, .cache in my case. It's okay with zipping up and saving them, but the restore always 204s (no content).
Renaming .cache to just cache or something else fixes it. But I guess this is a bug likely in the backend since the POST goes through fine with the correct size.
EDIT: I had some issues with hidden files too, but might be unrelated to this.
@jahed Thanks! I would not expect that, do you have a repro project/workflow you could send me so I can look into this?
i have some node modules that my custom actions depend on. i tried using hashfiles('.github/actions/package-lock.json') and it didn't like it.
I tried setting up a minimal reproduction but failed to reproduce the issue.
https://github.com/jahed/_actions-cache-repro
So that got me thinking. I moved my git repo to a new GitHub repo. Reverted back to .cache and it's working now. Changing the directory name to make it not hidden was a red herring.
So whatever it was... I don't know. I didn't change anything other than migrate repos. So maybe the repo on GitHub is just old, had some incompatible settings, failed some backend migration or something. It's a bit of a black box.
Anyways, I'm going to close this since I can't reproduce it. I'm encountering other issues with the cache too but it just seems very random. Next time I report something, I'll setup a minimal reproduction first.
@jahed Okay! Let me know if you need any help setting it up!
It's possible you had a corrupted cache at some point, and using the same key will keep fetching that cache over and over.
That would make sense. It would be nice to be able to download caches on our end in order to debug runs and see what's being restored.