Actions/cache: Cache not being hit despite of being present

Code to Cloud GitHub Actions
#1

Hi,

My workflow looks like this:

- name: Set Poetry Config
      run: |
        poetry config virtualenvs.create true
        poetry config cache-dir

    - uses: actions/cache@v1
      name: Poetry Cache
      with:
        path: ~/.cache/pypoetry/virtualenvs
        key: poetry-${{ runner.os }}-${{ hashFiles('poetry.lock') }}
        restore-keys: |
          poetry-${{ runner.os }}-

    - name: Install python dependencies
      run: make installdeps

The corresponding logs showed:

poetry config virtualenvs.create true
poetry config cache-dir
shell: /bin/bash -e {0}
env:
DEEPSOURCE_DSN: ***
pythonLocation: /opt/hostedtoolcache/Python/3.8.2/x64
/home/runner/.cache/pypoetry

Cache not found for input keys: poetry-Linux-10e15406c5ba2cd9517ecdbad0c577bdaeb25da4c86ef997a3082522bfa0d618, poetry-Linux-.
Run actions/cache@v1
  with:
    path: ~/.cache/pypoetry/virtualenvs
    key: poetry-Linux-10e15406c5ba2cd9517ecdbad0c577bdaeb25da4c86ef997a3082522bfa0d618
    restore-keys: poetry-Linux-

  env:
    DEEPSOURCE_DSN: ***
    pythonLocation: /opt/hostedtoolcache/Python/3.8.2/x64
Cache not found for input keys: poetry-Linux-10e15406c5ba2cd9517ecdbad0c577bdaeb25da4c86ef997a3082522bfa0d618, poetry-Linux-.

The post job logs show that cache was stored successfully:

Post job cleanup.
/bin/tar -cz -f /home/runner/work/_temp/d1cb4b2a-f400-44ba-ac17-8a863c548c95/cache.tgz -C /home/runner/.cache/pypoetry/virtualenvs .
Cache saved successfully

However, on the second run, the cache is missed again. Logs here:

Cache not found for input keys: poetry-Linux-10e15406c5ba2cd9517ecdbad0c577bdaeb25da4c86ef997a3082522bfa0d618, poetry-Linux-.
Run actions/cache@v1
  with:
    path: ~/.cache/pypoetry/virtualenvs
    key: poetry-Linux-10e15406c5ba2cd9517ecdbad0c577bdaeb25da4c86ef997a3082522bfa0d618
    restore-keys: poetry-Linux-

  env:
    DEEPSOURCE_DSN: ***
    pythonLocation: /opt/hostedtoolcache/Python/3.8.2/x64
Cache not found for input keys: poetry-Linux-10e15406c5ba2cd9517ecdbad0c577bdaeb25da4c86ef997a3082522bfa0d618, poetry-Linux-.

Does anyone have an idea about why the cache is being missed in the second run? Also, would it be apt to open an issue on https://github.com/actions/cache?

Thanks!

#2

@rj722 ,

I tested and tried as the demo you shared, but I did not reproduce the problem. Not sure what causes this problem.

I have helped you report this ticket in the repository of the cache action:

https://github.com/actions/cache/issues/231

You can follow this issue ticket, and add you comment here.

Of course, actually any user can directly open an issue this repository, that will allow you to directly interact with the appropriate engineering team, and make it more convenient for the engineering team to help you solve the problems occur when you use this action, and also can collect and categorize your suggestions for this action. I think this is why the team will set the repository to be public.

#3

@rj722 ,

I noticed the appropriate engineer has provided some suggestions for troubleshooting, please check with these:

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.

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.

#4

This doesn’t make sense to me. Seems like the cache should be dependent on the repo and the keys. Not on the branch. And in my experience, it only gets a cache hit on the same commit when I re-run the workflow. It never seems to get a hit even on the same branch. This is pretty silly.

1 Like
#5

Oh, so it’s scoped to the specific tag for runs triggered by a tag push as well. This is even more silly. It means that no tag build can use cache. Why do they scope it to the branch???

1 Like
#6

Hey. How did you figure out it is scoped to the tag as well?