When downloading 2 versions of Cypress simultaneously, one clobbers the other resulting in nondescript error and exit #4595
Comments
jennifer-shehane
added
type: bug
cli
stage: ready for work
|
We're running into this too! I hypothesized that something was being clobbered, but hadn't gotten very far into it yet. I happen to be using Cypress inside a container, so my current workaround is to make my base image |
|
Ran into the same issue when setting up a monorepo strategy in one of my company's project. In fact, in my case, the problem doesn't occur as specified by @jennifer-shehane. In my case, it only occurs because I'm installing two different versions of Cypress ( So, I think some things can help out
In my case, I changed my testing strategy to centralize e2e tests into a single place instead of having it divided by package. It was a possibility in my case. |
|
Our solution to this issue (which might not apply to everyone) is to install Since cypress is installed together with lerna and lerna is only able to run its tasks after that install, there are never conflicts with subsequent cypress installations since the binary already exists when the install on individual packages are run with lerna. We use CircleCI, here's a modified extract of our version: 2
defaults: &defaults
working_directory: ~/working_directory
environment:
CYPRESS_CACHE_FOLDER: '~/working_directory/.cache/Cypress'
docker:
- image: circleci/node:12.14.0-browsers
jobs:
install:
<<: *defaults
timeout: 1000
steps:
- run:
name: Install Dependencies without updating package-lock.json
command: npm install --no-save
- run:
name: Install package dependencies
command: npm run bootstrap -- --ci
- persist_to_workspace:
root: ~/working_directory
paths: ./**
test:
<<: *defaults
steps:
- attach_workspace:
at: ~/working_directory
- run:
name: Running tests
command: npm test
... |
|
I worked around this by setting env var |
|
I could have a go at solving this. Is that OK, @jennifer-shehane? |
|
Following @wmartins first suggest approach I've used selective version resolutions by adding cypress entry in the "resolutions" array. All the direct or transitive dependencies will resolve to the top level cypress version, in my case, cypress@4.10.0. |
|
For all my suggestions on circumventing the problem, see "Fixing/circumventing the problem" at #7951 |
|
@Vages Yes, feel free to an open a PR - even one that is a 'draft' is fine. Check out our contributing doc before getting started, but mostly we're pretty big on adding tests around what the PR is fixing 😉. |
@testing-library/cypress was downloading another version of Cypress; This would conflict with our installed version and crash on Travis CI; References: github.com/cypress-io/cypress/issues/4595
bahmutov
added
the
topic: installation
|
There seems to be a lot of comments in relation to mono repos but I don't think this issue is limit to this setup. Within our repo we have the following dependancies:
When inspecting the yarn lock you will notice that @types/testing-library__cypress has a dependancy of cypress "*" This results in: In addition to: This obviously results in two versions of Cypress being downloaded, resulting in this issue you have described, but in reality the 5.6.0 version should be the only one downloaded/used for the wildcard dependancy as it meets the requirements. For this reason I don't truly believe this issue is solely with Cypress but possibly with Yarn and/or other libs that use Yarn seems to be aware of this issues - yarnpkg/yarn#6695 |
Previously, we were accidently installing 2 versions of Cypress. See: cypress-io/cypress#4595
…117) * update actions/setup-node to 2.1.2 * update vercel-action to amondnet/vercel-action@v20. This also sets the default vercel scope to secrets.VERCEL_ORG_ID * fixes Cypress issues Previously, we were accidently installing 2 versions of Cypress. See: cypress-io/cypress#4595
the problem was because there are 2 versions of cypress being downloaded ref: cypress-io/cypress#4595
try skipping CYPRESS_INSTALL_BINARY ref: cypress-io/cypress#4595
When running the build, we were getting a "Corrupted Download" message when trying to install Cypress. I believe this is due to the `get-table` package requiring an older version of Cypress as one of its dependencies. Here's how I came to that conclusion: cypress-io/cypress#4595
cypress-bot
bot
added
stage: work in progress
and removed
stage: ready for work
|
Providing a more complete example of this to test if the PR opened will fix it:
{
"name": "ex-project",
"private": true,
"version": "1.0.0",
"main": "index.js",
"license": "MIT",
"workspaces": ["packages/*"],
"scripts": {}
}
{
"name": "foo",
"private": true,
"version": "1.0.0",
"devDependencies": {
"cypress": "6.3.0"
}
}
{
"name": "bar",
"private": true,
"version": "1.0.0",
"devDependencies": {
"cypress": "6.4.0"
}
} |
|
The code for this is done in cypress-io/cypress#14952, but has yet to be released. |
|
Released in This comment thread has been locked. If you are still experiencing this issue after upgrading to |
Current behavior:
We recently encountered an error on one of our repos ourselves where we use yarn. The problem was that we were downloading two versions of cypress within our
package.json. We run a monorepo, so one of the cypress versions was in the mainpackage.jsonand the other cypress version was in a sub-module of our monorepo.Since we save cypress upon download to
/tmp/cypress.zip, they were clobbering each other when both were being downloaded/unzipping at the same time. Due to how yarn works, this is likely to exhibit more frequently in it - although it's still possible using npm.Note: This can still happen even if the 2 Cypress versions are the same version number
Basically:
/tmp/cypress.zip/tmp/cypress.zipResulting in this error specifically:
See #3515 (comment)
Desired behavior:
When downloading Cypress, we need to make the
tmpdestination more unique like:/tmp/cypress-${version}-${random}.zipSteps to reproduce: (app code and test code)
project/packages/foo/package.json{ "name": "foo", "devDependencies": { "cypress": "3.3.2" } }project/packages/bar/package.json{ "name": "bar", "devDependencies": { "cypress": "3.3.2" } }Run
yarnVersions
Cypress 3.3.2
The text was updated successfully, but these errors were encountered: