Cypress GUI run against remote dev (WSL2, Codespaces, Docker, etc)

NicholasBoll commented 2 years ago

What would you like?

The Cypress GUI running against a remote development environment. Not using Xwindow forwarding or messing with complicated settings. Run the Cypress GUI pointing to a remote Cypress dev process.

Example:

On remote development environment (WSL2, Codespaces, Docker, etc).

cypress dev

This command would set up a cypress dev server for the GUI to connect to. This server would be responsible for all the requests the Cypress GUI usually asks for (test files, reloading when files are updated, bundling, etc).

The Cypress GUI can be started from the local environment either via cypress open or a different command. This method requires Cypress to be installed globally on the local machine. From here, the user has the ability to point the GUI to a remote development environment.

Why is this needed?

It is very difficult to set up x-window forwarding and it can be very slow streaming pixels from a remote machine. It is much more efficient to stream text and commands. Remote development is getting more popular with the release of more development environment solutions like Codespaces. In my own workflow, I use WSL2. In remote development, Cypress is the most painful tool to use. There are tutorials for getting X servers working, but even when the do work, the remote rendering looks terrible with HiDPI screens.

I've gotten by with cloning the repository I'm working with and starting Cypress against the local clone. The problem with this is it is easy to forget to copy/paste local Cypress spec file changes to the remote environment. The Cypress GUI seems to be tied to the local file system. VSCode has solved this problem making remote development seamless. I can install a Remote SSH, Remote WSL, or Remote Containers or connect to a Codespace, running a local version of VSCode and connect to a remote VSCode (server).

This would make remote development environments work much better with Cypress development.

Other

No response

levymp commented 1 year ago

+1 for adding the ability for remote development... would be great to have a command like the following: cypress open --e2e --skip-gui Then open the remote machine's instance of cypress in chrome to view/iterate on tests similar question has been asked here: https://stackoverflow.com/questions/53861190/using-cypress-test-runner-on-remote-development-server and here: https://stackoverflow.com/questions/60286652/running-the-cypress-test-runner-remotely

cypress-app-bot commented 1 year 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.

Kaiden42 commented 1 year ago

+1 X11 forwarding the browser from the remote machine is painfully slow and crashes multiple times a day 😕

Jack-G-Smith commented 1 year ago

+1

spaque99 commented 11 months ago

+1. I would love this feature

Xvpher commented 7 months ago

+1 Any updates on this feature?

theunkn0wn1 commented 7 months ago

+1 Several of our developers run the website under test on a remote system they SSH into. we just discovered npx cypress open doesn't work over a ssh shell as no UI opens.

for these developers, its not possible to run cypress locally.