How does this github-action know what version of Cypress to install?

[kpturner]

trafficstars

I am using v4 of this github action in two different workflows. We use it to install cypress in one step and run the tests in another step (having faffed around setting things up in between).

In one workflow, the install step installs V10 of Cypress. In the other workflow, it installs V9.7.0 of Cypress (and falls over because of the breaking changes the github-action expects to see regarding the config etc).

How does the github-action determine which version of cypress to install? There are no parameters to dictate this that I can see, so there, so there must be something subtly different between our two workflows but without knowing how the github-action decides what to install it is difficult to track down.

[kpturner]

I tried a custom cache key to try to force this to download and install the latest version (10.2( but to no avail. It still insists on installing 9.7.0

[kpturner]

Next I tried npx cypress cache clear and finally this github action did seem to install Cypress 10.2

I use the action to install Cypress, then I do various other things to set stuff up and also run npx cypress info to confirm things. The output is

10507:0626/123635.610003:ERROR:sandbox_linux.cc(377)] InitializeSandbox() called with multiple threads in process gpu-process.
[10507:0626/123635.613025:ERROR:gpu_memory_buffer_support_x11.cc(44)] dri3 extension not supported.
Displaying Cypress info...
Detected 2 browsers installed:
1. Chrome
  - Name: ***
  - Channel: stable
  - Version: 99.0.4844.51
  - Executable: google-***
  - Profile: /home/ubuntu/.config/Cypress/cy/production/browsers/***-stable
2. Firefox
  - Name: firefox
  - Channel: stable
  - Version: 101.0.1
  - Executable: firefox
  - Profile: /home/ubuntu/.config/Cypress/cy/production/browsers/firefox-stable
Note: to run these browsers, pass <name>:<channel> to the '--browser' field
Examples:
- cypress run --browser firefox
- cypress run --browser ***
Learn More: https://on.cypress.io/launching-browsers
Proxy Settings: none detected
Environment Variables:
CYPRESS_CACHE_FOLDER: /home/ubuntu/.cache/Cypress
Application Data: /home/ubuntu/.config/cypress/cy/development
Browser Profiles: /home/ubuntu/.config/cypress/cy/development/browsers
Binary Caches: /home/ubuntu/.cache/Cypress
Cypress Version: 10.2.0 (stable)
System Platform: linux (Ubuntu - [18](https://github.com/fotechgroup/systems/runs/7060744011?check_suite_focus=true#step:16:19).04)
System Memory: 33.2 GB free [31](https://github.com/fotechgroup/systems/runs/7060744011?check_suite_focus=true#step:16:32).4 GB

so on the face of it, it looks good.

I then run the tests and it falls flat on its face:

Skipping install because install parameter is false
Error: Cannot find module 'cypress'
Require stack:
- /home/ubuntu/actions-runner/_work/_actions/cypress-io/github-action/v4.1.0/dist/index.js

It is like pulling teeth!

[kpturner]

I fixed the "Error: Cannot find module 'cypress'" error by replacing the "project" parameter on the action with "working-directory" (because that was the parameter used on the call that did the install). So I guess my only remaining problem is the fact that the need to clear the cache rather defeats the whole object of having caching in place. I suppose that now the cache has been cleared once it will be OK on that particular runner - but I need it to be stable for all runners.

[admah]

@kpturner the action relies on the project it’s running against to determine the version of Cypress that's installed. The action itself has nothing to do with the version.

You can see a good example of this in the RWA actions here. If you click into “Cypress install” and scroll down you’ll see 10.1.0 is installed because that’s what the package.json has on that branch. master is actually set to 10.0.3.

Do you have any code that I could take a look at to see what the differences might be?

[kpturner]

@admah This is what I surmised, but it doesn’t seem to be particularly reliable as a way of determining the version to install.

A summary of what I have: Scenario 1 A repo that contains nothing but Cypress tests. In that repo is a workflow that checks out the repo and downloads an artefact containing the application to test. The application is installed and started. This GitHub action is used to install Cypress and run the tests. It installs the version defined in the package.json in the repo we have checked out. All good.

Scenario 2 A repo that contains the application but no reference to cypress at all. A workflow checks out the application code, build and starts it ready to be tested. The workflow then checks out the repo containing all the cypress tests. It checks it out to a subdirectory of the main repo (so it only exists for the duration of the workflow). This GitHub action is then used to install Cypress and specifies the subdirectory in the “project” parameter. It installs the wrong version - it doesn’t install the version defined in the package.json in the subdirectory you have defined in “project”. I have no idea how it decides what to install but it wasn’t the right version (9.7.0 instead). Everything else works - you can run the tests etc but not with expected version. If the test repo is configured to use v10 but it installs 9.7 it all falls apart.

There are two parameters on the GitHub action that seem to have similar import - “project” and “working-directory” so I had to fiddle with these AND clear out the cache to get it to install the correct version.

[kpturner]

I think what is happening here is simply a symptom of the way the installed version is cached. In scenario 2 it seems to simply installs whatever version it has cached regardless of what version the repo package.json says. So if we have a PR that is testing out aspects of Cypress 10, that gets installed and cached. A subsequent job that hits the same self-hosted runner may still be on version 9.7, but nevertheless the GitHub action seems to find a cached version and goes ahead and installs that even though it will be the wrong version - with breaking changes. We end up with version 10 code looking for a config file that would never exist in a repo written for 9.7. Running npx cypress cache clear every time seems to fix matters - but that kinda defeats the whole purpose of the cache. I would expect it to only install the cached version if it is the correct version.

[kpturner]

In fact even clearing the cache results in unexpected failure with no indication of what the failure is:

Received 4194304 of 190941409 (2.2%), 4.0 MBs/sec
Received 4194304 of 465288812 (0.9%), 4.0 MBs/sec
Received 88080384 of 190941409 (46.1%), 42.0 MBs/sec
Received 100663296 of 465288812 (21.6%), 48.0 MBs/sec
Received 167772160 of 190941409 (87.9%), 53.3 MBs/sec
Received 176160768 of 465288812 (37.9%), 56.0 MBs/sec
Received 190941409 of 190941409 (100.0%), 56.2 MBs/sec
Cache Size: ~182 MB (190941409 B)
/bin/tar -z -xf /home/ubuntu/actions-runner/_work/_temp/7a50e038-2fcb-447d-b2fa-f96432e4989b/cache.tgz -P -C /home/ubuntu/actions-runner/_work/systems/systems
Received 260046848 of 465288812 (55.9%), 62.0 MBs/sec
Received 343932928 of 465288812 (73.9%), 65.6 MBs/sec
Received 427819008 of 465288812 (91.9%), 68.0 MBs/sec
Received 465288812 of 465288812 (100.0%), 65.1 MBs/sec
Cache Size: ~444 MB (465288812 B)
/bin/tar -z -xf /home/ubuntu/actions-runner/_work/_temp/47a5afa8-3252-4ee0-af6f-47[15](https://github.com/fotechgroup/systems/runs/7238204766?check_suite_focus=true#step:15:16)7e60929a/cache.tgz -P -C /home/ubuntu/actions-runner/_work/systems/systems
Cache restored successfully
Cache restored successfully
/home/ubuntu/actions-runner/_work/_tool/node/[16](https://github.com/fotechgroup/systems/runs/7238204766?check_suite_focus=true#step:15:17).15.1/x64/bin/npm ci
npm WARN deprecated [email protected]: See https://github.com/lydell/source-map-url#deprecated
npm WARN deprecated [email protected]: Please see https://github.com/lydell/urix#deprecated
npm WARN deprecated [email protected]: https://github.com/lydell/resolve-url#deprecated
npm WARN deprecated [email protected]: See https://github.com/lydell/source-map-resolve#deprecated
npm WARN deprecated [email protected]: Debug versions >=3.2.0 <3.2.7 || >=4 <4.3.1 have a low-severity ReDos regression when used in a Node.js environment. It is recommended you upgrade to 3.2.7 or 4.3.1. (https://github.com/visionmedia/debug/issues/797)
npm WARN deprecated [email protected]: Chokidar 2 does not receive security updates since 20[19](https://github.com/fotechgroup/systems/runs/7238204766?check_suite_focus=true#step:15:20). Upgrade to chokidar 3 with 15x fewer dependencies
npm WARN deprecated [email protected]: Chokidar 2 does not receive security updates since [20](https://github.com/fotechgroup/systems/runs/7238204766?check_suite_focus=true#step:15:21)19. Upgrade to chokidar 3 with 15x fewer dependencies
npm WARN deprecated [email protected]: The querystring API is considered Legacy. new code should use the URLSearchParams API instead.
npm WARN deprecated [email protected]: Please upgrade  to version 7 or higher.  Older versions may use Math.random() in certain circumstances, which is known to be problematic.  See https://v8.dev/blog/math-random for details.
npm WARN deprecated [email protected]: The npm package has moved to @cucumber/cucumber
npm WARN deprecated [email protected]: core-js@<3.4 is no longer maintained and not recommended for usage due to the number of issues. Because of the V8 engine whims, feature detection in old core-js versions could cause a slowdown up to 100x even if nothing is polyfilled. Please, upgrade your dependencies to the actual version of core-js.
added 8[23](https://github.com/fotechgroup/systems/runs/7238204766?check_suite_focus=true#step:15:24) packages, and audited 8[24](https://github.com/fotechgroup/systems/runs/7238204766?check_suite_focus=true#step:15:25) packages in 7s
60 packages are looking for funding
  run `npm fund` for details
7 vulnerabilities (6 high, 1 critical)
To address all issues, run:
  npm audit fix
Run `npm audit` for details.
/home/ubuntu/actions-runner/_work/_tool/node/16.15.1/x64/bin/npx cypress cache list
┌─────────┬──────────────┐
│ version │ last used    │
├─────────┼──────────────┤
│ 9.5.4   │ a minute ago │
└─────────┴──────────────┘
Skipping running tests: runTests parameter is false
5s
Run npx cypress info
npm WARN exec The following package was not found and will be installed: cypress
An unexpected error occurred while verifying the Cypress executable.
Please search Cypress documentation for possible solutions:
https://on.cypress.io
Check if there is a GitHub issue describing this crash:
https://github.com/cypress-io/cypress/issues
Consider opening a new issue.
----------
Error: spawn /home/ubuntu/.cache/Cypress/9.7.0/Cypress/Cypress ENOENT
----------
Platform: linux-x64 (Ubuntu - [18](https://github.com/fotechgroup/systems/runs/7238204766?check_suite_focus=true#step:16:19).04)
Cypress Version: 9.7.0
Error: Process completed with exit code 1.

[admah]

@kpturner have you tried using custom cache keys as documented here?

The action does try to use the cached dependency folder and the cached Cypress binary. Binary caching definitely proved to be an issue for us internally while developing Cypress 10. Some days, I hit npx cypress cache clear more times than I'd like to remember.

[kpturner]

Yes tried a custom cache key but it didn’t seem to make any difference.

We are getting lots of issues having been kinda forced to update to 10.2 and cannot revert to 9.7 because we can’t force the the GitHub action to downgrade. It’s tempting to dispense with the github action completely.

[admah]

@kpturner I get that it's really frustrating, and wish that I had more to offer. I'm not entirely sure that it's a GH action issue, but a larger caching issue - whether GH or Cypress core. With your advanced setup it's hard to tell.

I'm interested to see if other users are having the same issue. I haven't seen any indications of that yet though.

[sergiomap]

we are also facing the same issue. We have version 9.5.4 of cypress in package.json but it insists to install the latest available (10.4.0). Since the end of June, it's possible to delete cache on Github Actions, and we tried that but this still happens even without cache.

[holoiii]

@kpturner were you able to make any progress on this? I am running into the same issue.

1. When cypress gets updated (in my case from 10.9.0 -> 10.10.0), the cached binary ends up being 10.10.0
2. The github action tries to run the 10.9.0 binary, which doesn't exist, and fails

My package.json:

"cypress": "^10.9.0"

yarn.lock:

"cypress@npm:^10.9.0":
  version: 10.9.0
  resolution: "cypress@npm:10.9.0"

[kpturner]

@kpturner were you able to make any progress on this? I am running into the same issue.

1. When cypress gets updated (in my case from 10.9.0 -> 10.10.0), the cached binary ends up being 10.10.0
2. The github action tries to run the 10.9.0 binary, which doesn't exist, and fails

My package.json:

"cypress": "^10.9.0"

yarn.lock:

"cypress@npm:^10.9.0":
  version: 10.9.0
  resolution: "cypress@npm:10.9.0"

Yeah I solved it by no longer using this github-action :) It wasn't really giving anything other than problems so I have made do without it.

[MikeMcC399]

@kpturner

I'm sorry to read that you stopped using github-action and I'm closing your issue now since it is no longer relevant to you.