Open johnnyreilly opened 4 years ago
@johnnyreilly Yes, Cypress requires Electron. There's an issue to separate this dependency from Cypress here: https://github.com/cypress-io/cypress/issues/3899 But yeah, there is likely some base dependencies missing in the devcontainers that make Cypress not open.
We have docker-images https://github.com/cypress-io/cypress-docker-images that may be helpful in tracking down whats missing.
This repo is only for issues relating to the Cypress product. If you want to open an issue on our docs, you can open it here. This issue will be moved to that repository.
Thanks @jennifer-shehane!
I spent some time digging into this yesterday and I'm wondering if what I'm outlining is possible or not. Given that devcontainers have no UI of their own (as I understand it anyway) - it's all communication over ports.
When you cypress open
to fire up the test runner you fire up an electron app in the context of the devcontainer not your host OS. That can't work (I guess) due to the lack of a UI in the devcontainer.
However, given you can also run the test runner in Chrome, I wonder if it's possible to trigger the test runner in the devcontainer but then connect to it using Chrome on your host OS be it Windows / Mac / Linux. Do you have an idea if that's even possible? Is the test runner accessible in that way? Can we go to http://localhost:7777 (I just made up a random port) and see the test runner? Or am I barking up the wrong tree? 🐩🌳
I managed to get cypress open
up and running in a VS Code Devcontainer backed by WSL2 and Docker using a X11 server.
devcontainer.json
:
"containerEnv": {
"DISPLAY": "host.docker.internal:0.0",
"LIBGL_ALWAYS_INDIRECT": "0"
}
VcXsrv
from https://sourceforge.net/projects/vcxsrv/ on the Windows hostVcXsrv
's XLaunch
program on the host. Use the default settings, but make sure to uncheck Native opengl
and check Disable access control
cypress open
in your VS Code terminal inside of the devcontainerThis recipe was adapted from https://marinerobotics.gtorg.gatech.edu/dev-notes/running-ros-with-gui-in-docker-using-windows-subsystem-for-linux-2-wsl2/
I can confirm the approach @larrifax suggested worked for me as well.
Another potential blog post to reference: https://nickymeuleman.netlify.app/blog/gui-on-wsl2-cypress
I used this blog post to get things working in WSL2 before attempting to do it within a container (which led me to this github issue) - I needed the config from step 1 in the above post to get the container piece working. I did not uncheck the Native opengl
option, but did check Disable access control
as noted. Was able to run cypress example specs.
Building on this I was able to use cypress open
in a Codespace thus:
Configure your devcontainer.json
to use Docker Compose, so you can:
Use x11-bridge
to have an X11 display you can point Cypress at (see snippet below).
Set "forwardPorts": [10000]
in devcontainer.json
so you can access x11-bridge
, then:
Launch Cypress with DISPLAY=:14 LIBGL_ALWAYS_INDIRECT=0 $(npm bin)/cypress open
docker-compose.yml
:
x11-bridge:
image: jare/x11-bridge
volumes:
- "/tmp/.X11-unix:/tmp/.X11-unix:rw"
ports:
- "10000:10000"
restart: always
environment:
MODE: tcp
XPRA_HTML: "yes"
DISPLAY: :14
XPRA_PASSWORD: MUST_BE_SOMETHING
Tada 🎉
@davetapley were you able to run this using the default free-tier of Codespaces, the 4 core • 8GB RAM • 32GB
option? Is your configured repository open source?
I'm running into following error with just the default specs generated by Cypress.
$ DISPLAY=:14 LIBGL_ALWAYS_INDIRECT=0 yarn cy open
yarn run v1.22.10
$ cypress open
[27314:1101/184846.887716:WARNING:discardable_shared_memory_manager.cc(194)] Less than 64MB of free space in temporary directory for shared memory files: 63
[27314:1101/184848.876579:ERROR:browser_main_loop.cc(1409)] Unable to open X display.
The futex facility returned an unexpected error code.
The Test Runner unexpectedly exited via a exit event with signal SIGABRT
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.
----------
Platform: linux (Ubuntu - 20.04)
Cypress Version: 8.7.0
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
@AriPerkkio yep I was able to run in that Codespace. I'm afraid the repo is not open source, but I don't see the WARNING
🤔
That said, I don't think the memory is the issue, I think Unable to open X display
is your real problem. Perhaps check that the DISPLAY=:14
is making it through to cypress open
?
Got it working now based on your instructions @davetapley! I'm finally able to run Cypress on my Chromebook.
I ended up documenting a minimal setup into https://github.com/AriPerkkio/cypress-codespaces-example.
Building on this I was able to use
cypress open
in a Codespace thus:
- Configure your
devcontainer.json
to use Docker Compose, so you can:- Use
x11-bridge
to have an X11 display you can point Cypress at (see snippet below).- Set
"forwardPorts": [10000]
indevcontainer.json
so you can accessx11-bridge
, then:- Launch Cypress with
DISPLAY=:14 LIBGL_ALWAYS_INDIRECT=0 $(npm bin)/cypress open
docker-compose.yml
:x11-bridge: image: jare/x11-bridge volumes: - "/tmp/.X11-unix:/tmp/.X11-unix:rw" ports: - "10000:10000" restart: always environment: MODE: tcp XPRA_HTML: "yes" DISPLAY: :14 XPRA_PASSWORD: MUST_BE_SOMETHING
Tada tada
if someone has more problems with this, you can find more information through this link.
https://devopstar.com/2022/01/03/cypress-testing-in-devcontainers-and-github-codespaces
@davetapley thanks to help on this, I can confirm that this solution works perfectly.
@Pakoke Have you found a way to make the Cypress app use all available browser space?
It's 2023 and there is still no real solution to this issue -- the x11 bridge solution is a workaround that feels slow and super sketchy.
Back in 2017/2018 Cypress was a game changer because of how it totally changed the way we do e2e testing. Will the next game changer be the one that works in Codespaces instead of relying on local machines to do e2e testing?
I'm running into this issue as well :-( Would be great if there was a flag to run cypress in the browser using a local server instead of a desktop app... It doesn't have to be the default, but it would allow to solve this situation easily, I believe. Cypress is already an electorn app so it's basically built using javascript and html, and it opens up something that looks very similar to a browser anyway... IDK, just a thought. Let me know if you think I should open an issue in the main repo. Documenting this is OK I guess, but supporting this out of the box is what would be ideal in this case. It's not only about codespaces but also WSL. My team and I for example have moved to use WSL when developing on windows and while recent changes made it easier to open UI things from WSL the problem my rise again...
Hi @HarelM , would you mind opening up a feature request in the main cypress-io/cypress repo? That way we can route it to our product team for review and consideration. Just to set realistic expectations, even if product agrees this is a direction they want to pursue for the app I would be surprised if this specific feature floated to the top of the list of priorities. If they do end up giving the thumbs up on the feature we would most likely need outside contributors to open a PR for this.
@nagash77 I just did: #27217 I hope this will happen sometime in the future :-)
Running Cypress GUI from inside a Development Container is possible with very minimal setup. Add desktop-lite to your devcontainer.json
file and forward the ports (ports can be customised, 6080
and 5901
are defaults as of this writing):
"ghcr.io/devcontainers/features/desktop-lite:1": {},
...
"forwardPorts": [6080, 5901],
Once your container runs, open http://localhost:6080 and login with the default password vscode
(can also be customised). Finally, run cypress open
and the Cypress GUI should be visible in your browser.
Hope this helps =)
@nicky-lenaers this is perfect! very minimal and worked really well!
Running Cypress GUI from inside a Development Container is possible with very minimal setup. Add desktop-lite to your
devcontainer.json
file and forward the ports (ports can be customised,6080
and5901
are defaults as of this writing):"ghcr.io/devcontainers/features/desktop-lite:1": {}, ... "forwardPorts": [6080, 5901],
Once your container runs, open http://localhost:6080 and login with the default password
vscode
(can also be customised). Finally, runcypress open
and the Cypress GUI should be visible in your browser.Hope this helps =)
This is really great solution! Unfortunately it is not easy to notice it in this thread :(
I spent a few hours yesterday trying to make x11-bridge
solution working but with no luck. And only today i noticed your brilliant comment with solution that just worked. Here is the full devcontainer file that works for me
{
"image": "cypress/included:13.6.6",
"forwardPorts": [6080, 5901],
"features": {
"ghcr.io/devcontainers/features/desktop-lite:1": {}
},
"portsAttributes": {
"6080": {
"label": "desktop"
}
},
"postCreateCommand": "npm install && cypress install"
}
Having read all this, I just want to be specific. I believe this issue isn't a case of splitting up Electron and Cypress into separate packages, given I suspect Electron is required to do all the low-level things Cypress does. More so, everyone here seems to be able to successfully get Cypress running. The issue is more around "how can we interact with the desktop-based UI when the app is hosted on another machine".
Whilst the "desktop-lite" path works, it's brittle, as is the X11 route given both are video proxies and highly tied to the OS. I believe the next step would be if anyone could give a gauge of any potential issues in providing a http-served version of the "Cypress web app" which seems to be a well-designed Vue-3 app. This would communicate via it's existing GraphQL client with it's electron backend via an opened port in Electron. This would allow user's to use Cypress via a browser (most likely by directly jumping into an interactive runner) solving this issue. I have some experience in all of these technologies but it could be quite a large change so would want buy-in from team Cypress before starting anything.
Hello everyone!
I ❤️ Cypress - it is an amazing product. Thanks for your work on it.
I've found myself doing more and more work lately using devcontainers as my development environment in VS Code.
The one thing that I haven't yet cracked is working out how to get Cypress fully working in a devcontainer. I've been able to get a part of the way there by using the Node example devcontainer here: https://github.com/microsoft/vscode-dev-containers/tree/master/containers/javascript-node-14
And tweaking it based upon the Cypress docs for CI here: https://docs.cypress.io/guides/guides/continuous-integration.html#Dependencies to add in the Cypress dependencies.
The tricky part is that whilst this gets us to the point of Cypress technically running, it doesn't show the Cypress Test Runner. Running
cypress open .
does not error which is lovely. However, crucially it doesn't fire up the Cypress Test Runner UI that you might expect. I imagine this is because the Test Runner uses an Electron app by default. I wonder if there's a way to do this by using the browser on the host machine (Chrome in my case) for the test runner.I'm not sure what the way forward here would look like and I'm curious if there are docs that explain how to get up and running with devcontainers. I haven't found any and I suspect this is going to become an increasingly common workflow - it's likely that many others are likely trying to do the same thing. The advent of approaches such as GitHub Codespaces will only add to the popularity!
I'd be happy try and help out with some docs on this if I knew just how do get this up and running. Any ideas?