working demo, waterfall and more

Thanks to Reed, I just put up my latest pet project up on the l10n server.

It’s offering a new web interface for buildbot builds. It does so by feeding the status data that buildbot has into a database on the one end, and on the other end is a django app displaying that data.

The nice thing about this is that writing features (or fixing bugs) is “just webdev”. Compared to whatever you want to call tinderbox hacking.

There are already a few concepts demoed on the site. All urls are in flux, note the “stage” in them. But the principle should be obvious.

Firstly, you can get to a regular waterfall on waterfall. Yes, there are some time-sorting issues there. But it’s quick, which is cool. Compare it to the regular buildbot waterfall (didn’t bother checking which timerange that shows). And it offers a nice compromise (IMHO) for displaying detail or not. For finished builds, it shows one box per build. For builds in progress, it shows a box per step (it doesn’t show a box for the build for those steps, which is confusing). It has a blame column, too. Whenever you see a change number, that links to a new page, which lists all builds for that particular change. This one shows an en-US check-in with all locales turning red, for example. Another one just shows how things go green for Arabic again, as that localizer checked in.

For the l10n builds, that’s peanuts, but if you’re landing on a tree with real compiles, being able to follow all builds for your landing, and no others sounds cool.

And django comes with helpers for generating feeds, so creating a meaningful live bookmark to follow your own landing doesn’t seem like an unsolvable RFE.

There’s more. You can restrict the waterfall to only show builds for a particular slave. You can restrict the shown builds to only show builds with a particular property, say, the Macedonian builds, compared to all builds.

There’s obviously lots of room for improvement, the code is in the tinder app in my hg repo. Volunteers welcome.

The Conversation {3 comments}

  1. Robert Helmer {Sunday January 4, 2009 @ 12:35 am}

    Looks great, any reason this can’t be used to do a general replacement of Tinderbox?

    I started a similar project “Millicent” (which we discussed in the infrastructure improvements subject in m.d.planning) but I think I like your approach better.

    The main thing I was concerned with was making a drop-in replacement for Tinderbox, which maybe would be better to do as a plug-in for Buildbot anyway and not have to create a third system.

  2. Axel Hecht {Sunday January 4, 2009 @ 10:57 am}

    Thanks.

    Regarding replacing tinderbox, I think there aren’t any technical reasons that can’t be solved.

    I don’t yet know how to do log parsers, and of course, logs need to be compressed on disk, and likely written outside the master dirs. I think that that should be subject to my next git branch.

    I do have ideas on how to do tree rule messages and trees in general, though I didn’t start with that yet.

    The question goes further though. Having the webdev piece on top of django is likely going to put us into a better place than tinderbox. It doesn’t put us into a place where the webdev piece is a real open source project with outside contributors, though. Maybe we have to bite that bullet to just get our development infrastructure improved and fix recent regressions like the blame column. But I anticipate a wider and more rational discussion on that.

    Right now, this is my personal baby, and I try to make it look like an attractive replacement for tinderbox, but whether it is or not is up to discussion.

  3. Axel Hecht {Friday July 31, 2009 @ 2:33 am}

    PS: The hg repo moved to http://hg.mozilla.org/l10n/django-site/.

Sorry, comments for this entry are closed at this time.