[Buildbot-commits] [Buildbot] #2670: describe/_describe are backward

[Buildbot trac]

#2670: describe/_describe are backward
----------------------+---------------------
Reporter:  dustin     |       Owner:  dustin
    Type:  undecided  |      Status:  new
Priority:  critical   |   Milestone:  0.8.9
 Version:  0.8.8      |  Resolution:
Keywords:             |
----------------------+---------------------

Comment (by dustin):

 It's worth noting, too, that the current situation is not a great user
 experience (although I'm sure lots of folks -- hi, thanks for visting this
 bug! -- are wedded to how it is).  Looking at the current metabuildbot, I
 see:

  name: git; status: update

  name: virtualenv_setup; status:  'PYTHON='python2.4'; VE='../sandbox-
 python2.4-Twisted==8.1.0-sqlalchemy==0.6.0samigr-0.7.1'; ...'
 name

  name: versions; status: versions

  name: test slave; status: 268 tests passed 3 skips

 Only the last of those really makes any sense.

 I think there are a few pieces of information useful to the user here:

  * step name
  * step status (what's going on RIGHT NOW)
  * step result (useful tidbits about the step)
  * build-level step result (tidbits the user may want to see at the build
 level)

 The middle two are mutually exclusive, and the first is orthogonal to all
 of this - step names are fixed early through a separate process.  The
 !BuildStep class itself knows if the step is finished, so there's no need
 to pass that information as a parameter.

 From the perspective of a build, there is one step running, which is best
 represented with the step name and maybe step status; and there is a
 collection of build-level results from finished steps.

 So, how about this:

  * A `BuildStep.getCurrentSummary` method which gets the step's current
 state, called only while running.
  * A `BuildStep.getResultSummary` method which gets the step's result and
 build-level result, called only after the step is finished.
  * a `BuildStep.updateStatus` method which is debounced (#2443) and calls
 the appropriate one of the two funtions above, then sticks the result in
 the appropriate places (!StepStatus on eight, data API on nine).

 A step would store two strings, then: step summary and build summary[1].

 This means that a test step could potentially call `updateStatus` for
 every test case; the debouncing would take care of rate-limiting the
 update messages, just like the batching takes care of limiting the number
 of messages for new log entries.  This would let users watch the tests run
 "live" on the build or step status pages.  Pretty cool, eh?

 [1] I hate these names - ideas?

-- 
Ticket URL: <http://trac.buildbot.net/ticket/2670#comment:3>
Buildbot <http://buildbot.net/>
Buildbot: build/test automation