It turns out that the path specified for the cache action is what will be added to the cache tarball but, unfortunately, not necessarily what will be extracted from it. A potential inconsistency is due to the fact that files from the path are added to the tarball with paths relative to the current working directory (even if path is absolute). This means that if we extract files from the tarball while working in a directory with a different nesting level, they end up not in the path but somewhere else.
This is what happens when the cache tarball is created in one of our workflows and extracted in another one: the regular runners work in /home/runner/work/rte-rrtmgp/rte-rrtmgp and the containerized ones in /__w/rte-rrtmgp/rte-rrtmgp. So, the cache generated by one workflow is not really used in another one, although the cache action reports on a hit.
A workaround for the issue is to use the same relativepath for both workflows, which is implemented in this PR.
It turns out that the
pathspecified for thecacheaction is what will be added to the cache tarball but, unfortunately, not necessarily what will be extracted from it. A potential inconsistency is due to the fact that files from thepathare added to the tarball with paths relative to the current working directory (even ifpathis absolute). This means that if we extract files from the tarball while working in a directory with a different nesting level, they end up not in thepathbut somewhere else.This is what happens when the cache tarball is created in one of our workflows and extracted in another one: the regular runners work in
/home/runner/work/rte-rrtmgp/rte-rrtmgpand the containerized ones in/__w/rte-rrtmgp/rte-rrtmgp. So, the cache generated by one workflow is not really used in another one, although thecacheaction reports on a hit.A workaround for the issue is to use the same relative
pathfor both workflows, which is implemented in this PR.