Adopt the terminology of "orchestrator" for the process that is running all of the servers and coordinating between them, just like in the design document. I'm not attached to this naming at all, but I think we should name it something, just to facilitate communication about what we're talking about.
Remove the main function and replace it with a function to construct an orchestrator. It's identical to the main function, aside from accepting options.
Set up a test helper of sorts which sets up an orchestrator with fixed ports which are different to the ones used by yarn start. This allos us to run a server via yarn start and run tests at the same time, which previously crashed.
The agent needs to be aware which port the orchestrator is running on so it can connect to it. Rather than guessing, the agent page will have to be loaded with a query param which points to the orchestrator. I've been racking my brain trying to come up with another way of doing this, but everything else I've come up with feels just as icky.
Rather than immediately loading the app through the proxy on load, the agent will wait for an open message from the orchestrator which will contain the URL to connect to. This way we don't have to hardcode it. I don't think that open will be an actual message later on (most likely we'll just say "run this test"), but this is just a temporary placeholder to make this work for now.
This commit adds no further tests, but it's sort of a pre-requisite to writing more tests, since we really need to be able to specify the ports for tests to make sense.
This commit makes a few changes:
Adopt the terminology of "orchestrator" for the process that is running all of the servers and coordinating between them, just like in the design document. I'm not attached to this naming at all, but I think we should name it something, just to facilitate communication about what we're talking about.
Remove the main function and replace it with a function to construct an orchestrator. It's identical to the main function, aside from accepting options.
Set up a test helper of sorts which sets up an orchestrator with fixed ports which are different to the ones used by
yarn start. This allos us to run a server viayarn startand run tests at the same time, which previously crashed.The agent needs to be aware which port the orchestrator is running on so it can connect to it. Rather than guessing, the agent page will have to be loaded with a query param which points to the orchestrator. I've been racking my brain trying to come up with another way of doing this, but everything else I've come up with feels just as icky.
Rather than immediately loading the app through the proxy on load, the agent will wait for an
openmessage from the orchestrator which will contain the URL to connect to. This way we don't have to hardcode it. I don't think thatopenwill be an actual message later on (most likely we'll just say "run this test"), but this is just a temporary placeholder to make this work for now.This commit adds no further tests, but it's sort of a pre-requisite to writing more tests, since we really need to be able to specify the ports for tests to make sense.