Issue with 2 step install / restore

[wyardley]

I'm running a 2-step install / run job on a couple projects that are using pnpm. This project had previously used the GH cache action directly to cache both node_modules and the Cypress cache, and I was trying to simplify; I was initially trying to use a simple example like https://github.com/cypress-io/github-action?tab=readme-ov-file#pnpm, but ran into issues because of running a separate build and run step.

So then I started trying to use something along the lines of:
https://github.com/cypress-io/github-action?tab=readme-ov-file#split-install-and-tests

That mostly works, but because I have some jobs that use the regular setup-node action with cache: pnpm set, I was running into some issues in terms of order of operations, and tried to switch the jobs to use a custom cache-key.

Slightly simplified / sanitized config:

jobs:
  build:
    name: Build
    runs-on: ubuntu-latest
    steps:
        uses: actions/checkout@v4
      - name: Setup pnpm
        uses: pnpm/action-setup@v4
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20.x
          # I've also tried cache: pnpm here
      - name: Install dependencies only
        uses: cypress-io/github-action@v6
        with:
          runTests: false
          cache-key: cypress-pnpm-${{ runner.os }}-${{ hashFiles('pnpm-lock.yaml') }}
        # Some build / cache steps here
  run:
    name: Run
    runs-on: ubuntu-latest
    needs: build
    timeout-minutes: 25
    strategy:
      fail-fast: false
      matrix:
        containers: [1, 2, 3, 4, 5, 6, 7, 8]
    steps:
      - uses: browser-actions/setup-chrome@v1
        with:
          chrome-version: stable
      - name: Setup pnpm
        uses: pnpm/action-setup@v4
      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: 20.x
      # some restore steps from the next build here
      - name: Cypress run
        uses: cypress-io/github-action@v6
        with:
          # [...]
          record: true
          install: false
          cache-key: cypress-pnpm-${{ runner.os }}-${{ hashFiles('pnpm-lock.yaml') }}

I'm getting various downstream errors with Cypress or other dependencies not being installed in the downstream job. The exact error seems to vary.

Is there a simple way to do what I'm trying to do, or is it better to continue using actions/cache@v4 directly?

[MikeMcC399]

@wyardley

Your workflow job run contains no steps to install dependencies (install: false) and relying on the presence and state of a cache can be problematic.

This issue list isn't really intended for "how-to" type implementation questions. It is more for bugs reports and enhancement requests, although there is always a grey area involved.

For "how-to" type support you can connect to the Cypress technical community on Discord

(click on button)

You may also want to check on the timings with and without caching. In some cases caching on GitHub-hosted runners can slow down workflows, which is counter intuitive, and even if caching speeds up the workflow, the gains may only be marginal. That is highly dependent on the project though. If caching is not beneficial, you may be able to simplify your workflow by omitting any additional caching definitions.

[wyardley]

Fair enough.
I had assumed that, at least with a dedicated cache key, it should be valid enough to use the instructions in https://github.com/cypress-io/github-action?tab=readme-ov-file#split-install-and-tests across two jobs, since run depends on build, and build should reliably save a cache to the expected key (not used by any other job) if it does not already exist. The docs imply that the pnpm deps will get saved in the cache, as well as that cypress itself will get installed and cached (if not already present). What wasn't super clear to me from the docs, though I can probably figure out from looking at the code, is if it's including both node_modules and the Cypress cache .

And yes, good point - I've seen the same thing as far as cache timings. I think in this case, since the caches are feeding a parallel workflow, it's partially done to avoid having each worker have to install the same dependencies, and we were also seeing some issues with npm rate-limiting, especially on self-hosted runners.

[MikeMcC399]

@wyardley

The docs imply that the pnpm deps will get saved in the cache, as well as that cypress itself will get installed and cached (if not already present). What wasn't super clear to me from the docs, though I can probably figure out from looking at the code, is if it's including both node_modules and the Cypress cache .

• The action has not implemented pnpm caching. See the open feature request Add dependency caching to pnpm #1044. This is not explicitly mentioned in the documentation.
• For npm and Yarn it is not the node_modules directory which is cached, it's the package manager's caches .npm or .cache/Yarn
• The Cypress cache .cache/Cypress is cached

To debug any workflow, follow the instructions in https://github.com/cypress-io/github-action/blob/master/README.md#debugging. In particular ACTIONS_STEP_DEBUG set to true will reveal exactly which files are being cached.

Good luck!