[Buildbot-devel] Why no ETA (sometimes)?

[Greg Ward]

Brian Warner wrote:
> The ETA is calculated using an exponentially-weighted average of previous
> builds (newavg = (newvalue+oldavg)/2 , so it's an IIR response), and the
> history is *not* currently saved to disk. As a result, you won't see an ETA
> until you've had at least one build since the Builder was created (i.e.
> modified) or the buildmaster was restarted. I seem to recall having code that
> would ignore the completion time of failing builds, or perhaps of builds
> which had steps skipped (e.g., if your compile step is marked
> haltOnFailure=True and it failed), the idea being that a build which fails
> and also does half as much work as usual shouldn't change our expectations
> about build time.
> 
> Does that sound like it might explain what you've seen?

Yep.  I figured it was something like that, but just wanted to be sure I
understood what was going on.

> That would be great.. feel free to create a ticket (or better yet a patch
> :-). The current scheme would require storing a dict of (metricname ->
> expectation) for each step. The builder pickle would be the most appropriate
> place for this.

Done: http://buildbot.net/trac/ticket/174

> The new scheme I'm thinking of would record a list of (time, progress)
> tuples, sampled maybe once every 5 seconds, for each metric*step. The idea is
> to create a graph of progress-vs-time, then transpose it to get a graph of
> time-vs-progress, then trim it down to a smaller number of samples and save
> it. [...]

Whoa.  Fancy.  I'd vote for the cheap 'n easy persistence fix first 
though.  Getting an ETA at all is IMHO more important than getting a 
super-duper whiz-bang ETA.

(And, BTW, getting an ETA is itself just icing on the cake.  It's a neat 
feature to show off, but I know how long a build takes and I can do the 
arithmetic in my head if need be.)

Greg