[Support]: Caching not working

[gabaum10]

What operating system are you using?

• [X] Linux
• [ ] macOS
• [ ] Windows

What version of the tool are you using?

gh version 2.18.1 (2022-10-20) gh valet github/gh-valet v0.1.16 valet-cli v0.1.0.13965

What happened?

After migration from circle CI, the caching wasn't migrated quite right. I attempted to clean it up based on the official actions docs, but it seems that every build is creating its own, new cache. Even if the hashes are the same.

This is what the steps which are installing the deps and setting up the caches look like:

install_parent_deps:
    name: Install Parent Deps
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Restore Parent Dep Cache
        uses: actions/cache@v3
        with:
          key: npm-parent-${{ hashFiles('package-lock.json') }}
          restore-keys: |-
            npm-parent-${{ hashFiles('package-lock.json') }}
            npm-parent-
          path: node_modules

      - name: Install Parent Dependencies
        run: npm ci

      - name: Save Parent Cache
        uses: actions/cache@v3
        with:
          path: node_modules
          key: npm-parent-${{ hashFiles('package-lock.json') }}

  install_web_deps:
    name: Install Web Deps
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Restore Web Dep Cache
        uses: actions/cache@v3
        with:
          key: npm-web-${{ hashFiles('veoci-web/package-lock.json') }}
          restore-keys: |-
            npm-web-${{ hashFiles('veoci-web/package-lock.json') }}
            npm-web-
          path: veoci-web/node_modules
      - name: Install Web Dependencies
        run: cd veoci-web && npm ci

      - name: Save Web Cache
        uses: actions/cache@v3
        with:
          path: veoci-web/node_modules
          key: npm-web-${{ hashFiles('veoci-web/package-lock.json') }}

Any guidance here would be super helpful.

Additional info: I also attempted to get rid of the manual caching and use the actions/setup-node@v3 to automatically set it up, but that doesn't seem to work correctly with our monorepo structure, even including a list of package.json files at the parent and each child directory.

Relevant log output

N/A - It's already been migrated, just not 100% correcrly.

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[gabaum10]

I may have figured this out. I don't think you need the second "save cache" step as it happens automagically from the first cache step defined. Can someone just confirm that for me?

[gabaum10]

No, that doesn't seem to be working either. It seems each branch/PR is generating its own cache for some reason. Is there not a way to work around that?

If not, it seems like we will run out of storage space very quickly.

[gabaum10]

Yeah, how odd. On a different branch I'm getting this:

Even though there is clearly a cache generated:

And it just saves another one. What on earth is going on.

[gabaum10]

Hmm ok, maybe this is working. I just triggered it off a branch from master, and it used the cache correctly.

[luke-engle]

Interesting, this is the from the 'cache action' documentation:

A workflow can access and restore a cache created in the current branch, the base branch (including base branches of forked repositories), or the default branch (usually main). For example, a cache created on the default branch would be accessible from any pull request. Also, if the branch feature-b has the base branch feature-a, a workflow triggered on feature-b would have access to caches created in the default branch (main), feature-a, and feature-b.

Access restrictions provide cache isolation and security by creating a logical boundary between different branches or tags. For example, a cache created for the branch feature-a (with the base main) would not be accessible to a pull request for the branch feature-c (with the base main). On similar lines, a cache created for the tag release-a (from the base main) would not be accessible to a workflow triggered for the tag release-b (with the base main).

Multiple workflows within a repository share cache entries. A cache created for a branch within a workflow can be accessed and restored from another workflow for the same repository and branch.

I'm not sure how your branches are set up but it seems like things should work assuming you're expecting cache from master to be used (and master is the default branch).

[gabaum10]

@luke-engle thanks for the response. Wait, so does that mean I should include the branch ref in the hash somewhere? Or the base branch maybe? That actually sort of makes sense... currently I'm just hashing off the various package-lock files.

      - name: Restore Parent Dep Cache
        uses: actions/cache@v2
        with:
          key: npm-parent-${{ hashFiles('package-lock.json') }}
          restore-keys: |-
            npm-parent-${{ hashFiles('package-lock.json') }}
            npm-parent-
          path: node_modules

[gabaum10]

What's very bizarre, is even the merges back on the base branch of master is generating a new cache for some reason...

Check that out, notice how the master branch has multiple web deps uploaded.

[luke-engle]

I'm honestly not sure 😞 I've never used actions cache before. Though it doesn't seem like you need to specify the branch in the hash - that data should already be available to actions cache. Perhaps this page could help clear up some confusion? https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows#using-the-cache-action

[ethanis]

Closing as this is not strictly related to Valet. I'd recommend filing an issue in the actions/cache repo if you need additional help from the team.