search

sbt / sbt-remote-control

Create and manage sbt process using unicorns and forks
Other
74 stars 14 forks source link

Improvements to support tracking execution #84

Closed havocp closed 10 years ago

havocp commented 10 years ago

With these changes people can monitor the execution queue and know which tasks are part of which execution request. Also some little related fixes/cleanups in their own commits.

jsuereth commented 10 years ago

So generally looks good. I think I've already seen some inconsistencies in detecting when a task is done if it returns events too fast on the client. I think we may need to alter the sbt.Client api a bit when running tasks so it provides more than one Future you can wait on, like result, exceutionId as well as isStarted, isFinished.

I think we should add a TODO in there now, as the new flatMap increases the likelihood of missing the event.

Otherwise LGTM. Nice work :)

havocp commented 10 years ago

I think we're providing enough API that the multiple futures (task result, isStarted, isFinished, etc.) could be implemented, but yeah there could be a convenience API which would basically keep a client-side model of the work queue and results. I was thinking that was part of the "cache" API we've been talking about. What you have to do in essence is always keep a client copy of the execution queue.

jsuereth commented 10 years ago

Hmm, ok. So for now we should mark a TODO on the sbt-terminal stuff and I'll rip into that (it's one of my blockers before a release), and then this is good to merge.

havocp commented 10 years ago

new commits pushed, I think I got all the comments

jsuereth commented 10 years ago

Great, thanks! Going to wait for TravisCI, then merge.

jsuereth commented 10 years ago

Wait, no TravisCI? DOH!!! I'll merge now, and work on travis ci