Re: Buildbot version

To add to that, I think we took this to mean there would be one master with a builder for each project/slave, with a category set on the builder of projectname so that we could just show the WebStatus stuff for a given project. So there would be something like:

projects = [ "list", "of", "modules", "from", "jhbuild", "list" ]
slaves = [ "server1", "server2", "server3"]

for project in projects:
    for slave in slaves:
        builder = {
            "name": project + slave,
            "factory": blah blah blah,
            "category": project }
    status.putChild(project, WaterfallStatusResource(categories=[project]))

Or something to that effect. We'd still have to write custom code to do the page, though.

On Thu, Jun 19, 2008 at 3:39 PM, Iago Toral Quiroga <itoral igalia com> wrote:
Hi Ilmar,

As you know we create one master per project, then we create a home page
that queries the state of each master and shows the summary. This
approach has its problems, since you need to open a lot of ports in the
case of big projects like Gnome.

About what the buildbot guys told us, you can find the details in the
mail archive of buildbot:

I put here the interesting part:

"I think you may be able to configure a single master with a number of
different waterfall views (exposed at different URLs, eg the current

One way to do this is with categories. A single master can have many
buildbot.status.web.waterfall.WaterfallStatusResources, each at a
different URL and each with different configuration. That resource
class accepts a `categories´ argument to its initializer. It will
only include builds from builders which have a `category´ which is
in that list.

For example, here's a snippet from Twisted's buildmaster configuration:

winxp32py25iocp = scmikesWinXP32.copy()
'name': "winxp32-py2.5-iocp",
'builddir': "WXP32-full2.5-iocp",
'factory': TwistedReactorsBuildFactory(blah blah blah),
'category': 'unsupported'})


WaterfallStatusResource(categories=['supported', 'unsupported']))

This gives us a waterfall with all our builders. We have another one
that only includes "supported". So, you could create a category for
each project and then a waterfall for each category. This done, you
should only need one slave process per slave machine, and they can
all talk to the same master."


El jue, 19-06-2008 a las 16:13 +0200, Ilmar Wilbers escribió:
> Hi John,
> Thanks for your reply. Could you give some insights as to what this
> alternative approach the buildbot team told you about consist of?
> ilmar
> John Carr wrote:
> > Hi Guys
> >
> >                 About make an update to a newer version of buildbot, I
> >                 think that John Carr
> >                 were trying to do that to the current stable buildbot
> >                 release (0.7.7) [1],
> >                 but I'm not sure if he gets a full support. I mean, he
> >                 didn't sent any patch
> >                 to the list.
> >
> >
> >             I can wait...
> >
> >
> >         I hope that Carr have just read this mail and could give us
> >         more information.
> >
> >
> > There is a branch [1] on the page you already linked to with the stuff
> > I was trying out. At this point, I don't think its worth upgrading the
> > existing scripts to 0.7.7. <http://0.7.7.> I had some major problems
> > migrating the waterfall views to the new WebStatus (can't remember the
> > current status, but I think they were partially working again but only
> > by shipping a file from buildbot 0.7.5 alongside our code) but we
> > already know our existing approach won't scale past a few buildbots
> > and were told of a different approach by the buildbot team.
> >
> > I've been meaning to try out this alternative approach but havent had
> > time. I'd like to have something running for GUADEC, though.... I'll
> > try and find some time to pick up on this.
> >
> > John
> >
> > [1]
> >
> _______________________________________________
> Build-brigade-list mailing list
> Build-brigade-list gnome org

Build-brigade-list mailing list
Build-brigade-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]