[Buildbot-devel] minor nit: remote status clients in "wait" and eta updates

[Brian Warner]

> From: Stephen Davis <stephendavis at mac.com>
> 
> I finally updated my real-time status client to work with 0.6.6 and  
> noticed that, after the build state changes to "waiting" with an  
> initial ETA of the tree stable timer time, the client doesn't get any  
> more ETA updates until the build starts.  I could just not show the  
> ETA when it's in the waiting state but I thought I'd ask if it would  
> be easy for the master to send ETA updates until the build starts.

Hm. The short answer is "it wouldn't be too hard, but it's unlikely to
happen" :).

And the short question is, what do you need it for?

In 0.6.6, the "waiting"-state ETA message is only sent once because the ETA
value is not going to change. The "building"-state ETA gets sent every
(configurable but defaults to something like) 30 seconds because the ETA
keeps changing, as more Progress objects report more progress along various
metrics. In both cases, the ETA message indicates how many seconds in the
future the action will be complete. The client is supposed to add this value
to the current time to get an absolute time, then update their local status
display however frequently they like to show a countdown. An absolute display
like "the build will finish at 6pm" does not require constant updating, a
relative display like "the build will finish in 37 seconds" does.

I *think* the remote-status interface is designed to make sure that the one
"waiting"-state ETA message gets sent to everybody, both clients that were
connected when the waiting state was entered, *and* to clients that connected
after the state transition. If not, it's a bug. But it's unlikely to be
fixed, because..

In the upcoming release (still in CVS), the "waiting" state has gone away
entirely. The job of the tree-stable-timer has moved over to the Schedulers.
I intend to add remote-status access to the Schedulers eventually, right now
I think you can get to them internally but not through PB. The status client
will need to pay attention to both the Schedulers and the Builders to create
the same sort of status display as you have in 0.6.6, but I haven't quite
figured out how it should all work yet. (I decided to get the build-process
stuff working and released first, *then* figure out how to display status for
it all).


If you want this in 0.6.6, then:

 if the actual problem is the hypothetical bug in which clients that connect
 after the "waiting"-state transition do not receive *any* ETA messages, then
 the fix would go into BuilderStatus.subscribe, or maybe
 StatusClientPerspective.builderChangedState

 if you need multiple ETA messages to be sent, you could create a recurring
 timer in subscribe() that calls builderChangedState each time it fires. You
 need to be careful to disable the timer when you're done with it, or when
 the client unsubscribes.

 if the actual problem is a different hypothetical bug in which new Changes
 that arrive (and therefore extend the tree-stable-timeout) don't trigger new
 calls to builderChangedState, then the fix would also be in BuilderStatus
 somewhere.

 

hope that helps,
 -Brian