Hello : )
I've tried to apply this action to my workflow but it seems like does not work properly.
On the post action step, it completed with Cache saved successfully. But on the next action event. It always displays Cache not found with the same key.
Could you please a little bit check on this example link ?
My workflow config:
- name: Get yarn cache
id: yarn-cache
run: |
echo "::set-output name=dir::$(yarn cache dir)"
- uses: actions/[email protected]
with:
path: ${{ steps.yarn-cache.outputs.dir }}
key: yarn-
pkg manager: yarn
env: Linux
Hey @Cerberus,
Could you turn on debug logging?
Set the secret ACTIONS_STEP_DEBUG to true
See Enabling step debug logging for more info
@joshmgross Here it is. link : )
@joshmgross This looks like an issue with the scope. While this commit is on the master branch, the scopes are referencing the tags, for example refs/tags/v1.0.30, instead of the master branch. Thus, it is successfully committing the cache, but unable to find the cache since the scope is different each time.
@Cerberus this sounds like something we'll need to fix on the backend. We'll keep you up to date.
@Cerberus Looking at this more, this is the expected behavior.
For caching, tags and branches are treated identically with respect to the cache scopes (which determines when you can read and write caches).
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.
Let me know if you have any questions
Thank you for your detailed explanation. : )
Actually I planed to cache it on master branch for testing. When I add it, everything should work as expected.
Most helpful comment
@joshmgross This looks like an issue with the scope. While this commit is on the master branch, the scopes are referencing the tags, for example
refs/tags/v1.0.30, instead of the master branch. Thus, it is successfully committing the cache, but unable to find the cache since the scope is different each time.@Cerberus this sounds like something we'll need to fix on the backend. We'll keep you up to date.