envato/medusa — pull request #6 by elseano (2014-03-30 23:21:35+00:00)
Title: [WIP] Better init process

This is a big rework of the medusa communication internals, and is a prelude to improving the init process.

Previously communication was via messages sent through STDIN/STDOUT. This can cause issues with other processes writing to these pipes. I wanted to be able to capture STDOUT when necessary, but not corrupt the message stream.

Messages are now sent via a TCP connection, with the idea that for a SSH worker the required port will be forwarded back to the master node. At the moment Runners also communicate over a TCP connection, but this can probably change back to a pipe (the PipeTransport class is a bit of a draft at the moment).

The internal message processing loop as been replaced with the `MessageStreamMultiplexer` class which handles multiple blocking calls to `MessageStream#wait_for_message`, and presents the messages back onto to master thread so we don't get threading issues in the event handlers.

There's also a new way to invoke medusa, using the `escort` gem, which helps achieve our goal as being as simple to use as rspec:

```
# Run 2 local workers on everything within the spec directory
medusa spec
```

```
# Run 4 local workers on everything within the spec directory
medusa --runners 4 spec
```

```
# Run 30 remote runners on everything within the spec directory
medusa -c user@somehost/30 spec
```

```
# Run 60 runners over 2 worker nodes on everything within the spec, and features directory
medusa -c user@somehost/30 -c user@someotherhost/30 spec features
```

Todo:

- [ ] Spawn a worker agent on a remote node: `medusa worker-agent start --runners 30`. Worker agents should be detected automatically and manage the machines resources across multiple builds.
- [ ] Put `PipeTransport` back as the runner communication transport with a worker.
- [ ] Test the `CucumberDriver`
- [ ] Write the `JavascriptDriver`
- [ ] Setup the initializers, including the `RSyncInitializer`.