[Buildbot-devel] master status

[Nick Trout]

> From: Brian Warner 
> > I've had a rethink and it looks like I can use
buildbot.status.client
> > and buildbot.clients.base.TextClient to do what I want. Just out of
> > interest, when do you use the client stuff for? Is the GTK client no
> > longer used, deprecated in favour of the waterfall?
> 
[...]
> polled status information for people who have a web browser. Not
everybody
> likes polling. Not everybody is willing to run a special client
program.

Ok, I agree.

> The PBListener status protocol can be the base for arbitrarily
> complex/pretty
> status clients. I have this vision of a big GUI program that starts
with a
> single box and a zoom slider: the box is green if everything is happy
and
> red
> otherwise. As you zoom in, the box turns into one box per Builder,
then
> two
> boxes (current build / most recent build), then the current build
expands
> into individual steps, then the steps expand into logfiles, etc. Such
an
> application is probably a long way off, but the realtime status
protocol
> is
> intended to support things like it.

This sounds interesting. At the moment I was just thinking of logging
messages and displaying these, but this remote query device sounds
interesting. I suppose this could just be done through a web interface,
it might be quicker. This might also allow user data to be tied into the
display more easily. Often there a stats that you might want to display
from a build which you might treat as just another HTML log, which might
also have its own details to "zoom into". E.g. in memory constrained
systems you might be interested in stats generated from the mapfile
about the size of the executable, or the data it uses.

> The 'buildbot debugclient' panel gives access to the "debug port",
from
> which
> you can reload the config file, inject a fake change, and force a
build.

I discovered this yesterday. This is a very handy tool.

> I'll
> throw in a few docs, but it isn't something I really intend to support
> directly.. it's very much a debugging-buildbot-itself kind of tool.

But it's actually quite useful for developing debugging configs as well.
Being able to reload you config on the fly and force changes is very
useful. If you keep having to restart you BB master it looks to users
like its very flaky, when you might just be refining the config, and
when you have several slaves this can happen quite often.


> I'll take a look.. FYI, the TextClient stuff (and the GTKClient that
sits
> on
> top of it) is probably due for a rewrite. I know that it was broken
after
> the
> most recent status API change (maybe around the 0.6.4 timescale?) and
I
> only
> half-fixed it afterwards (it used to show a count-down ETA timer, and
> doesn't
> now). That code will probably get ripped out and rewritten some day
soon.

One of the reasons I didn't run this code is because it uses GTK. You
might be better off rewriting it using Tkinter (the Python Tcl/Tk
wrapper). This comes with the standard Python install and is pretty
portable. The small debug apps should probably written using this.

We use wxPython (which I think is even more portable than Tcl/Tk). It
would be nice if you would consider this options as well. I think this
would be a better solution than PyGTK for the large GUI you describe
because it is more portable (and I would suspect more widely used in the
Python community than PyGTK?) Tkinter isn't that great for large GUI
apps because it lacks some useful widgets.

Nick