-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Docs on using Cypress in a devcontainer #2956
Comments
@johnnyreilly Yes, Cypress requires Electron. There's an issue to separate this dependency from Cypress here: cypress-io/cypress#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 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
This 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 |
Building on this I was able to use
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 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. docker-compose.ymlversion: '3'
services:
development:
build:
context: .
dockerfile: Dockerfile
- DISPLAY=:14
- LIBGL_ALWAYS_INDIRECT=0
depends_on:
- x11-bridge
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 DockerfileARG VARIANT=16-bullseye
FROM mcr.microsoft.com/vscode/devcontainers/javascript-node:${VARIANT}
RUN apt-get update && export DEBIAN_FRONTEND=noninteractive \
&& apt-get -y install --no-install-recommends \
libgtk2.0-0 \
libgtk-3-0 \
libgbm-dev \
libnotify-dev \
libgconf-2-4 \
libnss3 \
libxss1 \
libasound2 \
libxtst6 xauth xvfb
.devcontainer.json{
"dockerComposeFile": "docker-compose.yml",
"service": "development",
"forwardPorts": [
10000
]
} |
@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 That said, I don't think the memory is the issue, I think |
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. |
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 |
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 :-( |
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. |
Running Cypress GUI from inside a Development Container is possible with very minimal setup. Add desktop-lite to your "ghcr.io/devcontainers/features/desktop-lite:1": {},
...
"forwardPorts": [6080, 5901], Once your container runs, open http://localhost:6080 and login with the default password Hope this helps =) |
@nicky-lenaers this is perfect! very minimal and worked really well! |
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
|
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?
The text was updated successfully, but these errors were encountered: