Docs on using Cypress in a devcontainer

[johnnyreilly]

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?

[jennifer-shehane]

@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.

[johnnyreilly]

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? 🐩🌳

[larrifax]

I managed to get cypress open up and running in a VS Code Devcontainer backed by WSL2 and Docker using a X11 server.

1. I added the following to my devcontainer.json:

  "containerEnv": {
    "DISPLAY": "host.docker.internal:0.0",
    "LIBGL_ALWAYS_INDIRECT": "0"
  }

2. Rebuild the container
3. Install VcXsrv from https://sourceforge.net/projects/vcxsrv/ on the Windows host
4. Run VcXsrv's XLaunch program on the host. Use the default settings, but make sure to uncheck Native opengl and check Disable access control
5. Run cypress open in your VS Code terminal inside of the devcontainer

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/

[jameskaupert]

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.

[davetapley]

Building on this I was able to use cypress open in a Codespace thus:

1. Configure your devcontainer.json to use Docker Compose, so you can:

2. Use x11-bridge to have an X11 display you can point Cypress at (see snippet below).

3. Set "forwardPorts": [10000] in devcontainer.json so you can access x11-bridge, then:

4. 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 🎉

[AriPerkkio]

@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.

docker-compose.yml

version: '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

Dockerfile

ARG 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
    ]
}

[davetapley]

@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?

[AriPerkkio]

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.

[Pakoke]

Building on this I was able to use cypress open in a Codespace thus:

1. Configure your devcontainer.json to use Docker Compose, so you can:
2. Use x11-bridge to have an X11 display you can point Cypress at (see snippet below).
3. Set "forwardPorts": [10000] in devcontainer.json so you can access x11-bridge, then:
4. 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.

[ivandotv]

@Pakoke
Have you found a way to make the Cypress app use all available browser space?

[markgoho]

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?

[HarelM]

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...

[nagash77]

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.

[HarelM]

@nagash77 I just did: #27217
I hope this will happen sometime in the future :-)

[nicky-lenaers]

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 =)

[bachirelkhoury]

@nicky-lenaers this is perfect! very minimal and worked really well!

[vitalyal]

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 =)

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"
}

[tomatkapitalise]

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.