The coordinator now sends an immediate `DataflowStartTriggered` reply when receiving a `DataflowStart` command. This enables the CLI to directly attach to the dataflow and observe the build output.
To wait until the build/spawning is done, this commit introduces a new `WaitForSpawn` command, to which the coordinator replies with a `DataflowSpawned` message once the node has been started. We use this command for the `dora build` command.
Instead of running all the build commands directly, run them on their intended target machines through the coordinator.
This commit is a breaking change because a coordinator connection is now required for `dora build`.
The previous machine ID is still used, but optional. Users don't need to ensure that the chosen machine IDs are unique anymore because they are augmented with a UUID.
Runs a dataflow locally, without requiring any any daemon or coordinator
processes. Multi-machine dataflows are not supported. The default log
level is set to `INFO`, overwriting it is possible by setting the
`RUST_LOG` environment variable.
This exposes the internal `dora daemon --run-dataflow` command that we
use for testing.
This addition was proposed in
https://github.com/orgs/dora-rs/discussions/698#discussioncomment-11125465
.
The second commit adds a ctrl-c handler. On first ctrl-c, we send a stop
command to all nodes. On second ctrl-c, we exit immediately and kill all
spawned nodes. On third ctrl-c, we abort the process directly without
waiting (child processes keep running).
Make `dora-message` a dependency of `dora-core`, instead of the other way around. This way, we can continue to freely bump the version of `dora-core` with the other workspace crates, without introducing errors such as #708.