Seems caching is not working

[sztadii]

Description:
I used the cache option in one of my public repos, but dependencies are getting installed again.
I do not see any difference in the pipeline duration when I run it with or without cache.

https://github.com/sztadii/crypto-dashboard/actions

Action version:
Specify the action version

Platform:

• [x ] Ubuntu
• macOS
• Windows

Runner type:

• [x ] Hosted
• Self-hosted

Tools version:
node 14.19.0

[dmitry-shibanov]

Hello @sztadii. Thank you for your report. Actually the setup-node action does not cache node_modules. It caches global cache directory.

[sztadii]

@dmitry-shibanov then the "Caching packages dependencies" title is misleading, I think it should be changed.

[DoWhileGeek]

I too, thought it would cache my node_modules, and assumed it would bust the cache when the defined lock file changed? The whole feature is quite misleading.

[jorupp]

I agree, I think that makes the statements on https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows that imply you should use actions/setup-node@v2 instead of actions/cache misleading.

[ThisIsMissEm]

I too hit into this when trying to optimise a CI pipeline, and was misled.

[ThisIsMissEm]

It could also be related to this PR: #323

[jessepinho]

I had the same question, and this article pointed out that you actually want to use actions/cache@v2, rather than actions/setup-node@v2. (You can still use the latter as well — it's just not going to cache your node_modules.)

[dmitry-shibanov]

Hello everyone. We updated documentation in scope of this pull request. For now I'm going to close the issue. If you have any concerns feel free to ping us.

[markusjohnsson]

@dmitry-shibanov : Actually the setup-node action does not cache node_modules. It caches global cache directory.

I see that you have updated the docs since this issue were opened, but could you also add a comment about what that means? What is the purpose of caching the global cache directory? When do I need this feature? Would caching node_modules not be a good idea (for me and/or for setup-node)?

[janbrasna]

I think the misunderstanding comes from outside of this actual repo, in a way how that caching concept is described in a workflows 101 article in GitHub Docs:

• https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows
  GitHub Actions / Using workflows / Cache dependencies

Caching dependencies to speed up workflows

To make your workflows faster and more efficient, you can create and use caches for dependencies and other commonly reused files.

Workflow runs often reuse the same outputs or downloaded dependencies from one run to another. For example, package and dependency management tools such as Maven, Gradle, npm, and Yarn keep a local cache of downloaded dependencies.

Jobs on GitHub-hosted runners start in a clean runner image and must download dependencies each time, causing increased network utilization, longer runtime, and increased cost. To help speed up the time it takes to recreate files like dependencies, GitHub can cache files you frequently use in workflows.

To cache dependencies for a job, you can use GitHub's cache action. The action creates and restores a cache identified by a unique key. Alternatively, if you are caching the package managers listed below, using their respective setup-* actions requires minimal configuration and will create and restore dependency caches for you.

That basically reads what everyone in this thread also thinks: Using cache should save time downloading and building node_modules over and over again. If using e. g. npm/yarn that means for one to use setup-node and have that caching taken care of.

Is there a way how this difference in mental model and expectations mismatch can be fixed documentation-wise?

(I myself still don't know how to describe the difference in caching the .npm/* deps vs. the actual built node_modules, so that any readers or action users would be able to understand what is possible to cache, and what is not real. Could anyone provide an entry-level material to understand this difference so that it might get updated in the GH Docs to be more specific?)

[haveaguess]

For future readers, I've setup caching/restore of node_modules and then just run npm install after to ensure it's all good. This mostly works although you should be aware there are reasons they haven't designed it like this, you may have weird issues with things that rely on native extensions other folders (e.g Puppeteer uses ~/.cache folder so we added that)

Here's relevant yaml from our action that caches our node_modules across our monorepo:

    steps:
      # attempt to cache/restore node_modules and npm using the GitHub Actions cache feature for faster builds.
      - name: Checkout
        uses: actions/checkout@v4

      - name: Install NodeJS
        uses: actions/setup-node@v4
        with:
          node-version-file: .node-version
          cache: "npm"

      - name: Cache + Restore node_modules
        uses: actions/cache@v4
        with:
          # Cache node_modules and Puppeteer chrome
          path: |
            ~/.cache
            node_modules
            nmg-analytics/node_modules
            slate-app/node_modules
            slate-extension/node_modules
            master-analytics-scripts/node_modules
          key: ${{ runner.os }}-node_modules-${{ hashFiles('**/package-lock.json') }}
          restore-keys: |
            ${{ runner.os }}-node_modules-

      - name: List the state of node modules
        continue-on-error: true
        run: npm list

      - name: Update Dependencies
        run: npm install

      - name: List the state of node modules again
        run: npm list
      # cache/restore complete

      - name: Integration Tests
        run: npm run test-integration