I run Linux 20.04.
Cypress open gets stuck loading when booting up.
This is what it looks like
When doing a fresh install on the desktop with "npm install -D cypress" I can choose the e2e test category, it creates the default folder structure and config then it gets stuck on the same screen.
Cypress run dosen't do anything at all.
Has anyone else experienced similar issues?
Related
npx npm run cypress --headless running this code in my project is still opening up a google chrome user, requiring UI to keep it going
no matter what I try, even uninstalling and reinstalling cypress doesn't fix the issue
The correct way is:
cypress run
Actually by default this command is executed in headless mode, that's why it's not necessary to write --headless. And if you want to run it in headed mode, then:
cypress run --headed
I've been using Cypress locally on my MacBook for some time and it's been going great. Lately my device has been having trouble, so I set up WSL on my PC so I could have a backup in case the worst were to happen.
We use yarn to handle dependencies, and I used NPM to install Cypress and Yarn.
Originally everything I was installing was going into a mounted virtual drive, where nothing was working. I eventually got it running off the linux directory, and Yarn and the dependencies installed fine. I also was able to install Cypress#9.5.4, which is the current version I'm using.
Every time I try to run Cypress headed or headless, I'm being met with the following:
No version of Cypress is installed in: /home/workterminal/.cache/Cypress/9.5.4/Cypress
Please reinstall Cypress by running: cypress install
----------
Cypress executable not found at: /home/workterminal/.cache/Cypress/9.5.4/Cypress/Cypress
----------
A couple coworkers took a stab at it, and this is as far as we could get before I decided to reach out for help here. We got me off the mounted virtual drive, we got NPM and Yarn installed properly after using the linux directory, and then reinstalled Cypress using yarn add cypress#9.5.4, which completed successfully.
We've tried expanding $PATH to include everywhere where Cypress exists, but it always looks in .cache. What can I do to toubleshoot further?
Problem
I want to be able to run my tests in terminal, but all my tests fail due to Cypress using Electron as the default browser and I want it to utilize Chrome, but without having to specify it in the command line.
Current Outcome
I know I can use the command npx cypress run --browser chrome to tell Cypress to use Chrome instead. However, it opens the browser AND runs it in command line.
Expected Outcome
Ideally it would only require me to run npx cypress run and this would only run in the command line using Chrome.
Summary
Is there a way to set the default browser to Chrome instead of Electron so I wouldn't need to specify which browser to use?
Is there something to add to the package.json file to set the default browser to Chrome or a line to inject somewhere? I checked the docs and I couldn't really find anything other than the --browser command.
** Cypress Github Open Issue **
Here is the link to the open issue on their github regarding a headless chrome and also to change the default for cypress run
Support chrome headless and change defaults for cypress run
Photo for the debugger
Sorry for the terrible scribbles...I am under an NDA so had to go back and scratch out all the path names for my project as well as my last name.
Cypress 3.8.1+ allows you to pass --headless to cypress run to make Chrome invisible on any operating system by using Chrome headless:
cypress run --headless --browser chrome
Outdated answer below:
There is not currently a way to hide Chrome in run mode on macOS or
Windows.
We'd like to support it, but we'd have to find some kind of workaround
for xvfb not being available. We can't use google-chrome
--headless either because it won't allow us to install the Cypress extension.
The advice below will only work for Linux.
npx cypress run --browser chrome is the correct way to do what
you're trying to do.
If you are on Linux, you can make it run Chrome in a virtual
framebuffer (so it will be hidden from you) by blanking out the
DISPLAY env variable:
DISPLAY= npx cypress run --browser chrome
Technical explanation:
Cypress does not support running in "headless Chrome" - headless Chrome was not around when Cypress was first written
So, when Cypress is running in Chrome in CI, it uses xvfb to create an X virtual framebuffer, then it uses the DISPLAY variable
to tell Chrome to run in the xvfb
However, if you have DISPLAY set (by default, it is set on Linux if you have a display manager), it will use that DISPLAY instead -
this is why it appears even though you're doing cypress run.
Adding DISPLAY= before the command nulls out DISPLAY, which means that Cypress will spawn xvfb and run it inside of there
instead.
I am trying to run any GUI container I can on MacOS. With every container I try (firefox, chrome, tor, spotify, etc) I always get the error Error: cannot open display. And it's not specific to the docker run command where I pass the environment flag with my $DISPLAY. When I try to run xhost + I get the same error.
I have a fresh XQuartz installation. It is up and running. I have turned on "allow connections from network" under security. I've tried building my own images and pulling jessie frazelle's images. I do not suspect it is a docker issue or the Dockerfiles. It is something on the host, my laptop. I can't seem to figure out what it is.
MacOS Sierra 10.12.5
Docker 17.12.0 Stable
XQuartz 2.7.11 (xorg-server 1.18.4)
My local's $DISPLAY is set to :0.0
So I finally got this to work. And it seems it was pretty simple. I am not certain how this actually fixes the issue, but now the containers work.
How I fixed it was opening up XQuartz and then opening up the "Terminal" app from the "Applications" menu. Then running the command export DISPLAY=192.168.1.X:0, then xhost +. It outputted something like this "access control disabled, clients can connect from any host". After that I was able to run my docker run commands to launch the desired GUI containers.
I am still uncertain how this works and not running them from my laptops Terminal app, but it worked. It must be something I have set in my local env. Hopefully this helps someone else out who may be running into the same issues.
Based on #Byron's answer, I've found out that I could get it to work by running these 2 commands in the normal terminal:
export DISPLAY=:0
/opt/X11/bin/xhost +
I'm trying to set up CI on my local machine running on Mac. To do so I use Xubuntu virtual machine, Jenkins, and some simple selenium tests. tests on github
I get fresh install of Xubuntu, where I install Jenkins using official manual.
In Jenkins I installed some plugins(git, ruby, rake, rbenv).
In job config I use rbenv wrapper(2.1.0) with ignorance of os versions, also I use this gemlist:
bundler,rake,rspec,selenium-webdriver,capybara
and running that job with
rspec spec
And when I run this job I recieve something like that for every test:
Selenium::WebDriver::Error::WebDriverError:
unable to obtain stable firefox connection in 60 seconds (127.0.0.1:7055)
full output is here
it looks like jenkins user have no access to display to run/see firefox.
Anyone know how to make it work?
We ran into this at work recently and actually opted for Capybara and set the driver to poltergeist. This seemed better than trying to figure out how to run FF on our VM's.
That said, we were able to get a small test suite running by following the instructions here
Answer was not so simple as I think.
The problem is that jenkins service has no access to displays (when it installed via native package). Thats why when I try to start Firefox it's throw me a error. try:
$ sudo su - jenkins && firefox
So it's need access to display to start browser successfully.
This is how I done it:
first of all I used answer form here where I changed to my local user.
Then I installed xvfb plugin to Jenkins, and in my build job preset display to '0' - which is my actual user display. with that option all my tests would run 'headless' but on actual display.
This could be not the best way to solve my problem, but it definitely works for me.