Open just-jeb opened 2 years ago
This issue has not had any activity in 180 days. Cypress evolves quickly and the reported behavior should be tested on the latest version of Cypress to verify the behavior is still occurring. It will be closed in 14 days if no updates are provided.
Activity bump.
@just-jeb
Have you referred to the documentation https://docs.cypress.io/guides/continuous-integration/introduction#Running-headless-tests-without-Xvfb and tried out the workaround there?
Are you still using the old Cypress 9.3.1
version or have you updated in the meantime?
I will check it out, thanks!
@just-jeb have you confirmed this is still happening on the latest version of Cypress?
@MikeMcC399 As noted in the documentation, that flag is experimental. In my experience I've never been able to get it to work. See
Unfortunately we have to close this issue due to inactivity. Please comment if there is new information to provide concerning the original issue and we can reopen.
@nagash77 inactivity might be the wrong reason here as there has been multiple replies in the last week. There seems to be a lot of issues being closed recently that are still issues, which is does not inspire confidence in the direction of the project from a user’s perspective.
@rooby this ticket is for a quite old version of Cypress. Since v9 of Cypress A LOT has changed in the app. As such we ask that users verify the behavior is still present in the latest version of Cypress. If you have a reproducible example of this behavior you can share in a version >12.0 please comment back here and we will be happy to investigate.
@nagash77 Yes this is still an issue in the newer versions. I just tested with cypress 12.12, using the cypress/included:12.13.0 Docker image and cypress-example-kitchensink (which was using cypress 12.12).
The command was explicitly headless: cypress run --browser chrome --headless
And with DEBUG=cypress:*,xvfb
it logs
> cypress-example-kitchensink@0.0.0-development cy:run
> cypress run --browser chrome --headless
cypress:cli:cli cli starts with arguments ["/usr/local/bin/node","/localDebugRepo/node_modules/.bin/cypress","run","--browser"
,"chrome","--headless"] +0ms
cypress:cli NODE_OPTIONS is not set +0ms
cypress:cli:cli program parsing arguments +1ms
cypress:cli:cli running Cypress with args ... +78ms
cypress:cli parsed cli options { browser: 'chrome', headless: true } +81ms
cypress:cli verifying Cypress app +0ms
cypress:cli Using CYPRESS_CACHE_FOLDER from environment variable +0ms
cypress:cli Using CYPRESS_CACHE_FOLDER from environment variable +0ms
cypress:cli using environment variable CYPRESS_CACHE_FOLDER /root/.cache/Cypress +0ms
cypress:cli checking environment variables +1ms
cypress:cli checking if executable exists /root/.cache/Cypress/12.12.0/Cypress/Cypress +2ms
cypress:cli Binary is executable? : true +2ms
cypress:cli binaryDir is /root/.cache/Cypress/12.12.0/Cypress +0ms
cypress:cli Reading binary package.json from: /root/.cache/Cypress/12.12.0/Cypress/resources/app/package.json +4ms
cypress:cli Found binary version 12.12.0 installed in: /root/.cache/Cypress/12.12.0/Cypress +3ms
cypress:cli { verified: true } +4ms
cypress:cli is Verified ? true +1ms
cypress:cli:run processing run options { browser: 'chrome', headless: true, key: null, spec: null, reporter: null, reporterOpt
ions: null, project: '/localDebugRepo' } +0ms
cypress:cli:run --key is not set, looking up environment variable CYPRESS_RECORD_KEY +1ms
cypress:cli:run run to spawn.start args ["--run-project","/localDebugRepo","--browser","chrome","--headed",false] +0ms
cypress:cli undefined DISPLAY environment variable +0ms
cypress:cli Cypress will spawn its own Xvfb +0ms
cypress:cli Using CYPRESS_CACHE_FOLDER from environment variable +10ms
cypress:cli Using CYPRESS_CACHE_FOLDER from environment variable +0ms
cypress:cli using environment variable CYPRESS_CACHE_FOLDER /root/.cache/Cypress +1ms
cypress:cli needs to start own Xvfb? true +0ms
cypress:cli Starting Xvfb +1ms
xvfb lock filename /tmp/.X99-lock +0ms
xvfb lock filename /tmp/.X99-lock +0ms
xvfb setting DISPLAY :99 +0ms
xvfb all Xvfb arguments [ ':99', '-screen', '0', '1280x1024x24' ] +1ms
xvfb checking if started by looking for the lock file /tmp/.X99-lock +3ms
xvfb checking if started by looking for the lock file /tmp/.X99-lock +10ms
xvfb lock file /tmp/.X99-lock found after 10 ms +1ms
cypress:cli spawning, should retry on display problem? false +16ms
cypress:cli passing DISPLAY :99 +4ms
cypress:cli spawn args [ '--no-sandbox', '--', '--run-project', '/localDebugRepo', '--browser', 'chrome', '--headed', false, '
--cwd', '/localDebugRepo', '--userNodePath', '/usr/local/bin/node', '--userNodeVersion', '18.16.0' ] { detached: false, stdio: [
'inherit', 'inherit', 'pipe' ] } +0ms
cypress:cli spawning Cypress with executable: /root/.cache/Cypress/12.12.0/Cypress/Cypress +0ms
cypress:cli piping child STDERR to process STDERR +3ms
cypress:snapshot:info Caching 3791, defining 4730 modules! Using cache +0ms
cypress:snapshot:debug initializing packherd require +0ms
cypress:server:performance-benchmark elapsed time at v8-snapshot-startup-time: 151.056ms +0ms
cypress:server:appdata path: /root/.config/Cypress/cy/production/browsers +0ms
cypress:server:cypress starting cypress with argv
...
Notably:
cypress:cli needs to start own Xvfb? true +0ms
cypress:cli Starting Xvfb +1ms
@rooby Do you know where I can find information that states chrome headless doesn't need xvfb?
@AtofStryker
Do you know where I can find information that states chrome headless doesn't need xvfb?
@MikeMcC399 I wonder if we can just pass in the browser to the isNeeded function and return false if chrome and headless? Could be a good first PR for a contributor.
@AtofStryker
I wonder if we can just pass in the browser to the isNeeded function and return false if chrome and headless? Could be a good first PR for a contributor.
That would definitely be worth investigating although @rooby stated that ELECTRON_RUN_AS_NODE=1
, which is also used in that code, never worked for him. Perhaps this is also dependent on the environment docker / no docker and OS in use?
@AtofStryker
I wonder if we can just pass in the browser to the isNeeded function and return false if chrome and headless? Could be a good first PR for a contributor.
That would definitely be worth investigating although @rooby stated that
ELECTRON_RUN_AS_NODE=1
, which is also used in that code, never worked for him. Perhaps this is also dependent on the environment docker / no docker and OS in use?
That or maybe the variable isn't spawned correctly in the process. Something that should be verified either way.
I confirmed this issue with Cypress 12.13.0 under Ubuntu 20.04 and Node.js 18.16.0
See repo https://github.com/MikeMcC399/cy-xvfb-test Workflow run 5187602242
Edit: Still failing in Cypress 12.16.0
I confirm that it fails in Cypress 12.17.2 as well. We are using Jenkins CI and Docker. The issue was more frequent in Cypress 10.10 and we recently migrated from v10 to v12. Running with ELECTRON_RUN_AS_NODE=1 and explicitly specifying --headless as in the node script below seemed to have worked for while with v10.10 however in v12.17.2 , this has re-surfaced.
`
`
@navedanjum Update: In my case, the issue occurred only on Debian 11.6 and the main reason, agent(slave) was running other UI tests that uses xvfb. Removing the --network="host" from Jenkins Docker run command solved the issue. In few pipelines we needed the host network so that didn't help, we simply had to ignore the executor to pickup the bad agent ( Debian - 11.6) by using Jenkins label : https://www.jenkins.io/doc/pipeline/steps/workflow-durable-task-step/#node-allocate-node
if using docker-compose.yml , removing network_mode: host will solve the issue.
I am also seeing this issue on Cypress 13 with Angular 17.
When running Cypress tests through Angular CLI on a Linux CI environment (GitHub Actions), Cypress is being launched twice, once with Chrome and once with Electron. This is causing unexpected behaviour:
ng e2e --configuration ci --browser chrome
Cypress should only run once with the specified browser (Chrome in this case).
"e2eci": "ng e2e --configuration ci --browser chrome"
"e2e": {
"builder": "@cypress/schematic:cypress",
"options": {
"devServerTarget": "app:serve",
"watch": true,
"headless": false,
"browser": ""
},
"configurations": {
"ci": {
"baseUrl": "http://localhost:4204",
"headless": true,
"ssl": false
}
}
}
angular.json::e2e contains a definition of browser to trample the defaults in Cypress code, this obviously doesn't resolve it.
"browser": ""
2024-07-05T00:00:36.152Z cypress:cli:run processing run options { project: '/home/runner/work/[PROJECT]/[PROJECT]/frontend', browser: 'chrome', headless: true, record: false, spec: null, devServerTarget: 'app:serve', watch: true, baseUrl: 'http://localhost:4204', ssl: false, configFile: undefined, quiet: false, e2e: true, component: false, env: '{}', exit: true, key: null, parallel: false, reporter: null, 'reporter-options': '{}', tsConfig: undefined, testingType: undefined, projectPath: '/home/runner/work/[PROJECT]/[PROJECT]/frontend/cypress', devServerBaseUrl: 'http://localhost:4204', dev: false, config: '{"e2e":{"baseUrl":"http://localhost:4204"}}', outputPath: '/tmp/tmp-1914-WtGMBrcDqLGb', reporterOptions: null }
...
2024-07-05T00:00:36.189Z cypress:cli spawning Cypress with executable: /home/runner/.cache/Cypress/13.13.0/Cypress/Cypress
...
Browser: Chrome 126 (headless)
...
2024-07-05T00:00:36.956Z cypress:cli:run processing run options { headed: false, record: false, parallel: false, quiet: false, component: false, outputPath: '/tmp/tmp-1771-tNzq5Bxu5uXl', key: null, spec: null, reporter: null, reporterOptions: null, project: '/home/runner/work/[PROJECT]/[PROJECT]/frontend' }
...
Browser: Electron 118 (headless)
Xvfb is being used for the headless runs:
cypress:cli undefined DISPLAY environment variable
cypress:cli Cypress will spawn its own Xvfb
The double run seems to be triggered by the interaction between Angular CLI and the Cypress schematic.
This behavior is not observed on Windows environments, suggesting it might be related to the Linux-specific setup or the use of Xvfb.
I would appreciate any insights into why this double run is occurring and how it can be prevented while still using the Angular CLI for running Cypress tests.
I attempted to use ELECTRON_RUN_AS_NODE=1 to inhibit the xvfb behaviour but that just caused #18224 which points back to this issue. No dice.
/opt/hostedtoolcache/node/20.15.0/x64/bin/npx cypress verify
2024-07-05T00:31:25.695Z cypress:cli:cli cli starts with arguments ["/opt/hostedtoolcache/node/20.15.0/x64/bin/node","/home/runner/work/[PROJECT]/[PROJECT]/frontend/node_modules/.bin/cypress","verify"]
2024-07-05T00:31:25.696Z cypress:cli NODE_OPTIONS is not set
2024-07-05T00:31:25.696Z cypress:cli:cli program parsing arguments
2024-07-05T00:31:25.699Z cypress:cli parsed cli options {}
2024-07-05T00:31:25.783Z cypress:cli verifying Cypress app
2024-07-05T00:31:25.783Z cypress:cli Using CYPRESS_CACHE_FOLDER from environment variable
2024-07-05T00:31:25.783Z cypress:cli Using CYPRESS_CACHE_FOLDER from environment variable
2024-07-05T00:31:25.784Z cypress:cli using environment variable CYPRESS_CACHE_FOLDER /home/runner/.cache/Cypress
2024-07-05T00:31:25.784Z cypress:cli checking environment variables
2024-07-05T00:31:25.791Z cypress:cli checking if executable exists /home/runner/.cache/Cypress/13.13.0/Cypress/Cypress
2024-07-05T00:31:25.793Z cypress:cli Binary is executable? : true
2024-07-05T00:31:25.793Z cypress:cli binaryDir is /home/runner/.cache/Cypress/13.13.0/Cypress
2024-07-05T00:31:25.793Z cypress:cli Reading binary package.json from: /home/runner/.cache/Cypress/13.13.0/Cypress/resources/app/package.json
2024-07-05T00:31:25.798Z cypress:cli Found binary version 13.13.0 installed in: /home/runner/.cache/Cypress/13.13.0/Cypress
2024-07-05T00:31:25.799Z cypress:cli could not read binary_state.json file at "/home/runner/.cache/Cypress/13.13.0/binary_state.json"
2024-07-05T00:31:25.799Z cypress:cli {}
2024-07-05T00:31:25.800Z cypress:cli is Verified ? undefined
2024-07-05T00:31:25.800Z cypress:cli force verify
2024-07-05T00:31:25.800Z cypress:cli running binary verification check 13.13.0
[STARTED] Task without title.
2024-07-05T00:31:25.803Z cypress:cli clearing out the verified version
2024-07-05T00:31:25.805Z cypress:cli Environment variable ELECTRON_RUN_AS_NODE detected, xvfb is not needed
2024-07-05T00:31:25.805Z cypress:cli needs Xvfb? false
2024-07-05T00:31:25.805Z cypress:cli spawning, should retry on display problem? false
2024-07-05T00:31:25.805Z cypress:cli disabling Electron sandbox
2024-07-05T00:31:25.805Z cypress:cli running smoke test
2024-07-05T00:31:25.805Z cypress:cli using Cypress executable /home/runner/.cache/Cypress/13.13.0/Cypress/Cypress
2024-07-05T00:31:25.805Z cypress:cli smoke test command: /home/runner/.cache/Cypress/13.13.0/Cypress/Cypress --no-sandbox --smoke-test --ping=776
2024-07-05T00:31:25.805Z cypress:cli smoke test timeout 30000 ms
2024-07-05T00:31:26.[48](https://github.com/[PROJECT]/[PROJECT]/actions/runs/9801235292/job/27064340185#step:5:49)9Z cypress:cli Smoke test failed: Error: Command failed with exit code 9: /home/runner/.cache/Cypress/13.13.0/Cypress/Cypress --no-sandbox --smoke-test --ping=776
/home/runner/.cache/Cypress/13.13.0/Cypress/Cypress: bad option: --no-sandbox
/home/runner/.cache/Cypress/13.13.0/Cypress/Cypress: bad option: --smoke-test
/home/runner/.cache/Cypress/13.13.0/Cypress/Cypress: bad option: --ping=776
at makeError (/home/runner/work/[PROJECT]/[PROJECT]/frontend/node_modules/cypress/node_modules/execa/lib/error.js:59:11)
at handlePromise (/home/runner/work/[PROJECT]/[PROJECT]/frontend/node_modules/cypress/node_modules/execa/index.js:114:26)
at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
shortMessage: 'Command failed with exit code 9: /home/runner/.cache/Cypress/13.13.0/Cypress/Cypress --no-sandbox --smoke-test --ping=776',
command: '/home/runner/.cache/Cypress/13.13.0/Cypress/Cypress --no-sandbox --smoke-test --ping=776',
exitCode: 9,
signal: undefined,
signalDescription: undefined,
stdout: '',
stderr: '/home/runner/.cache/Cypress/13.13.0/Cypress/Cypress: bad option: --no-sandbox\n' +
'/home/runner/.cache/Cypress/13.13.0/Cypress/Cypress: bad option: --smoke-test\n' +
'/home/runner/.cache/Cypress/13.13.0/Cypress/Cypress: bad option: --ping=776',
failed: true,
timedOut: false,
isCanceled: false,
killed: false
}
2024-07-05T00:31:26.[49](https://github.com/[PROJECT]/[PROJECT]/actions/runs/9801235292/job/27064340185#step:5:50)0Z cypress:cli error message: /home/runner/.cache/Cypress/13.13.0/Cypress/Cypress: bad option: --no-sandbox
/home/runner/.cache/Cypress/13.13.0/Cypress/Cypress: bad option: --smoke-test
/home/runner/.cache/Cypress/13.13.0/Cypress/Cypress: bad option: --ping=776
2024-07-05T00:31:26.491Z cypress:cli detecting arch { osPlatform: 'linux', osArch: 'x64' }
2024-07-05T00:31:26.499Z cypress:cli arm uname -m result: { stdout: 'x86_64' }
[FAILED] Cypress failed to start.
@nevercast
This should probably be a new issue.
@nevercast
This should probably be a new issue.
Seemed related. Felt the context may help. I shall move it to a new issue and reference this one.
@nevercast ! Any other instance of Cypress running on machine/server ? , if you're using the shared infrastructure resources. Xvfb issues we had resolved on the past because we had number of cypress jobs ran on the same linux server and we had to ensure the dockerized cypress tests do not share resource with the hosts to get rid of it. Your issue does not seem like one I am mentioned but often other job runs leave out xvfb process running on the machine.
If we run with chrome, can we remove xvfb dependency in the future?
@gweesin
If we run with chrome, can we remove xvfb dependency in the future?
That is the request in this issue. The issue is however still open, so there is no answer to your question at the moment.
@gweesin
If we run with chrome, can we remove xvfb dependency in the future?
That is the request in this issue. The issue is however still open, so there is no answer to your question at the moment.
Thank you for your reply, I'll pay attention to the progress. 😀
I'm experiencing this same issue, only way for us to resolve it is to go in and manually kill Xvfb processes and then rerun the tests.
@nevercast ! Any other instance of Cypress running on machine/server ? , if you're using the shared infrastructure resources. Xvfb issues we had resolved on the past because we had number of cypress jobs ran on the same linux server and we had to ensure the dockerized cypress tests do not share resource with the hosts to get rid of it. Your issue does not seem like one I am mentioned but often other job runs leave out xvfb process running on the machine.
Nope, no other processes on the server. GitHub Actions is spawning a fresh runner every time.
@nevercast
Did you ever open a separate issue? There is something wrong, apart from xvfb, if Cypress is being run twice. If you haven't done so already, I suggest again to open a new issue and post your GitHub Actions workflow.
@nevercast
@nevercast
- Your issue sounds very similar to Cypress is executing twice, making an additional electron execution github-action#974
Thanks! Yep. That was the issue. npm run e2e
was specified in start:
🤦♂️
@nevercast
It was added to the github-action
documentation start-server a while back:
Caution: use the
start
parameter only to start a server, not to run Cypress, otherwise tests may be run twice. The action runs Cypress tests by default, unless the parameterrunTests
is set tofalse
.
comment for activity and vis. I look forward to remove Xvfb dependency for ci 🕯️
Another comment for activity. Please remove the Xcfb dependency.
Current behavior
Cypress starts
Xvfb
even when running with Chrome Headless, which causesdisplay already in use
error when running multiple Cypress processes.Desired behavior
Cypress shouldn't run
Xvfb
if run with Chrome Headless.Test code to reproduce
Xvfb
on its own).yarn --frozen-lockfile
yarn ci
Cypress Version
9.3.1
Other
I'm aware of the possibility of running
Xvfb
on my own or spawning multiple machines, but this issue shouldn't be happening in first place, because Chrome Headless doesn't requireXvfb
.