Event Streaming (take 2) #320
Conversation
Reporting events to clients isn't useful without context. To provide that context, we add the NixFile for the shell.nix that represents the project to the Events.
We need to communicate within the daemon process when a new listener joins, so that we can start fanning out build events to them. That message needs to follow the same channels as the existing build_loop::Events do, once they get to the daemon. The solution is a wrapping enum (LoopHandlerEvent) that carries the build_loop::Events as well as NewListener messages.
The stream_events message will require a new method in the varlink interface to request a stream of build events, and then to receive that stream. Adds that method, implements it on the daemon varlink server, and builds conversion traits between the varlink types and their lorri analogues.
Streamed events are designed to be consumed by machine parsers of JSON (e.g. jq). Therefore the events that are to be emitted need to be serializable as JSON. This also includes serializing type names (for instance) in snake case, and changing a couple of types to be easier to serialize. Notably, error::BuildError::Exit carries an Option<i32> instead of a process::ExitError.
Finally, with the machinery in place, the UI to deliver the streamed event feature.
|
I left a little review (#183 (review)) and a couple of comments (#183 (comment), #183 (comment)) on #183 before seeing this new PR. I was going to suggest you rebase on top of Just as a note: I have no issue at all with you force-pushing to the branch of an existing PR like #183, IMO there's no need from the reviewer's point of view to create a new PR. But I'm happy to follow along. |
|
I had another think about this and spoke to @grahamc. Here's what I suggest we do:
I'm happy to help as much or as little as you like with each of those steps. @nyarly how does that sound to you? |
@curiousleo That plan sounds great to me. I would really like to get a nicer version of the example scripts into |
|
@nyarly wrote:
Excellent - congratulations, and thank you for your contributions so far! I've created #324 to keep track of the follow-up items we've discussed. |
|
Is this command supposed to return constant output ? |
|
|
|
I mean: |
Closes #145 #78 #79.
This PR should replace #183 - if this is acceptable, please close that PR.
Overview
Adds a
lorri internal__stream_eventssubcommand that returns a continuous stream json formatted representations of events. Each event is its own \n separated line. The command takes an option to toggle current state reporting vs. live events (or both), which is useful for the motivating use cases.Checklist
release.nix(seerelease.nixfor instructions)