Open reith opened 9 months ago
Running into the same issue, though downgrading to v2 doesn't seem to resolve it in my repo.
This comment helped me realize that the resolved path
is different between the two jobs, even though I use the same relative path in both configurations.
In my case, the non-containerized job uses a working directory of /home/runner/work/repo-name/repo-name
, while the containerized job uses a working directory of /__w/repo-name/repo-name
. (Maybe related: https://github.com/actions/runner/issues/2058)
It would be nice if actions/cache could use the relative path in selecting matches rather than the resolved absolute path.
For now, I'm working around the issue by just creating the duplicate caches, but I suppose you could also work around the issue by copying the cached files to a common absolute path and/or using symlinks.
Just stumbled upon this problem with v4 too. Any idea what might be missing in the container for caching to work?
The container image we use is golang
.
Bumped into this issue yesterday, but luckily remembered reading a related ticket that detailed the nuances of cache restoration. TD;LR: Ensure sufficient/matching compression tools are available from both container and non-container runtimes:
I populate a cache in one job running on an
ubuntu-latest
machine and try to read the cache in another job that runs in anubuntu
container. The workflow fails when I use v3 but succeeds with v2.v3 sample:
The first job succeeds - while there is complain in logs - and the second job fails:
Also, while
fail-on-cache-miss
is set, it actually doesn't terminate the job and I need another step, false here, to terminate the job.v2 sample, which works:
Logs: