feat: Set up cypress in cypress

[ryanthemanuel]

• Closes Unification: Support testing Cypress within Cypress #19547

User facing changelog

N/A

Additional details

From the list of items on the parent issue, the ones done with this PR are crossed off. The ones not will be handled by separate PRs, but with this change it should unblock people from writing tests

Namespacing

• General routes need to be namespaced
  • We will ensure that we are both utilizing the namespace on the client and factoring in the namespace in our route handling on the server
  • Currently the config is being retrieved via a call to the server. This will prevent the child Cypress instance config from being able to be loaded properly on the client since it doesn't know to namespace the API call yet. We will fix this by rendering the cypress config to the initial page server side in a global variable that can then be utilized client side to access the config.
• Websockets need to be namespaced
  • We will ensure that we are using the config.socketIoRoute as the path wherever we are creating a websocket
  • The proxied websockets from parent cypress to child cypress do not create an initial http connect event and thus the socket is not added to the allowed list for the child app server. Solution for this is TBD. For now, we will pass a header from parent to child signifying that this is a safe request. The child will only honor this header if we are in Cypress in Cypress mode
• Graphql requests need to be namespaced

Other Problems

• Connecting to an already existing browser
  • Since we already have a browser running when the child cypress server starts, we will need to set up a remote connection. We will do this by using CDPAutomation to attach to the existing browser instead of opening a new browser instance when we are in cypress in cypress. In order to facilitate this we are going to launch cypress in cypress tests with the environment variable set that specifies the remote debugging port. Also we are focused only on chrome

How has the user experience changed?

N/A

PR Tasks

• Have tests been added/updated?
• [na] Has the original issue (or this PR, if no issue exists) been tagged with a release in ZenHub? (user-facing changes only)
• [na] Has a PR for user-facing changes been opened in cypress-documentation?
• [na] Have API changes been updated in the type definitions?
• [na] Have new configuration options been added to the cypress.schema.json?

[cypress-bot]

Thanks for taking the time to open a PR!

• Create a Draft Pull Request if your PR is not ready for review. Mark the PR as Ready for Review when you're ready for a Cypress team member to review the PR.
• Become familiar with the Code Review Checklist for guidelines on coding standards and what needs to be done before a PR can be merged.

[cypress]

---

Test summary

18554 • 0 • 219 • 0 • 1

---

Run details

Project	cypress
Status	Passed
Commit	be38c7a
Started	Jan 14, 2022 10:18 PM
Ended	Jan 14, 2022 10:32 PM
Duration	13:24 💡
OS	Linux Debian - 10.10
Browser	Multiple

View run in Cypress Dashboard ➡️

---

Flakiness

	cypress/e2e/commands/net_stubbing.cy.ts		1
1	network stubbing > waiting and aliasing > can timeout waiting on a single request using "alias.request"

---

This comment has been generated by cypress-bot as a result of this project's GitHub integration settings. You can manage this integration in this project's settings in the Cypress Dashboard

[ryanthemanuel]

@lmiller1990 regarding #19602 (comment) I think as I was going through I was just ensuring that we are being consistent everywhere with the namespace. Good to know that package is going away though.

[tgriesser]

My only concern was that if we set HTTP_PROXY_TARGET_HOST / CYPRESS_REMOTE_DEBUGGING_PORT here, we might miss it if Cypress is started from the root of the project, etc.

Can we set these as additional "internal" config values that we can set on the packages/app/cypress.config.ts? It looks like they're only accessed when the browser is opened, so that should be fine since the config is sourced prior to that. @brian-mann thoughts?

[brian-mann]

I would prefer not to since they're not like... official config values / flags, and may end up getting removed anyway

[brian-mann]

I'm not sure what CYPRESS_REMOTE_DEBUGGING_PORT does anyway... is this the port like in --inspect-brk=[port] ?

[ryanthemanuel]

@brian-mann CYPRESS_REMOTE_DEBUGGING_PORT is the port that is used to launch the chrome debugger. I need a way to ensure that the parent and child are using the same port.

[tgriesser]

We have a lot of these already:

cypress/cli/types/cypress.d.ts

Lines 2896 to 2923 in 29f5c64

	// Internal or Unlisted at server/lib/config_options
	autoOpen: boolean
	browserUrl: string
	clientRoute: string
	configFile: string
	cypressEnv: string
	devServerPublicPathRoute: string
	isNewProject: boolean
	isTextTerminal: boolean
	morgan: boolean
	namespace: string
	parentTestsFolder: string
	parentTestsFolderDisplay: string
	projectName: string
	projectRoot: string
	proxyUrl: string
	remote: RemoteState
	report: boolean
	reporterRoute: string
	reporterUrl: string
	socketId: null | string
	socketIoCookie: string
	socketIoRoute: string
	spec: Cypress['spec'] | null
	specs: Array<Cypress['spec']>
	xhrRoute: string
	xhrUrl: string
	}

- what alternative would you suggest?

[ryanthemanuel]

@tgriesser Setting these on packages/app/cypress.config.ts doesn't seem to be early enough for parent cypress

Edit: The above comment is with respect to setting an environment variable in the cypress config file. I imagine if we add a first class internal config this will work.

[tgriesser]

I think this looks great - as pointed out there's a few things we might be able to improve upon around the sockets & env variables needing to be passed by the CLI, but overall I think it's good to merging and iterate from here