Cache: Cache always not found (yarn + linux)

Created on 11 Jan 2020  路  5Comments  路  Source: actions/cache

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

question

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.

All 5 comments

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

gladhorn picture gladhorn  路  4Comments

hugovk picture hugovk  路  6Comments

binkley picture binkley  路  4Comments

binhxn picture binhxn  路  3Comments

s-weigand picture s-weigand  路  5Comments