@achew22 I like it. The profiler in #87 could be wired up to this concept with some modifications. The complications that I'd have with this as is are:

1. I'm creating a profile event if and when the livereload is triggered which would require lifecycle events to be able to create new lifecycle events.

2. Change detection events pass the name of the change which wouldn't fit in the beforeEvent() afterEvent() pattern.

I think a few changes could make this more flexible. With different lifecycle event types requiring different parameters and the interface being the natural place to define those parameters, the event types and parameters could be defined by the lifecycle interface as such:

type Lifecycle interface {
	// Initialize is called when iBazel starts
	Initialize()

	// RunTarget is called when a target is being setup to run
	RunTarget(target string, rule *blaze_query.Rule)

	// ChangeDetected is called when a change is detected
	// changeType: "source"|"graph"
	// name: name of source file or build graph change
	ChangeDetected(changeType string, name string)

	// Called before/after running a command
	// commandType: "build"|"test"|"run"
	// success: true when command succeeded, false when failed
	BeforeCommand(commandType string)
	AfterCommand(commandType string, success bool)

	// Called after a livereload is triggered
	ReloadTriggered()

	// Cleanup is called when iBazel is being shutdown
	Cleanup()

For triggering a ReloadTriggered() event from within an AfterCommand() event, a Lifecycle interface could potentially be passed into to each event which could then be used to create other events as such:

AfterCommand(lifecycle Lifecycle, commandType string, success bool)

Thoughts?

@gregmagolan

I'm creating a profile event if and when the livereload is triggered which would require lifecycle events to be able to create new lifecycle events.

Live reload is currently triggered by an event. Could we have have the profiler note the time when they received the before/after event and say "that's how long it took"? The profiler may be a special case where we add some profiling code into one of the lifecycle listeners, but I'd like to avoid it if possible.

Change detection events pass the name of the change which wouldn't fit in the beforeEvent() afterEvent() pattern.

Thanks for the feedback! I'll be updating my commit in just a second to reflect your desired changes. One of the nice things about this interface is that all the implementors are going to be in the same repo so if we want to make changes we still can. In addition to the success information I would like to pass the action's run output. It might be possible to do some nifty things with the test output where you print out a reformatted form of the test output that's easier to read. Or, in the case of a build failure, the liveserver pushes a message to the browser that says "Hey, you had a typo on line 12 of foo.ts and your build didn't work".

@ittaiz, that's one of the many things I think we can solve with this. We can write a relatively simple post execution hook that will get the blaze $COMMAND output buffer after the program exits, parse it for magic strings, and then invoke bazel run //:gazelle or buildozer add ... or whatever it is you think should be run afterward.

@mrmeku, thanks for the review. Really good comments which I will address individually when I upload more code in a little bit.