[Buildbot-devel] multi-repo support: build triggers

Tobias Oberstein tobias.oberstein at tavendo.de
Tue Apr 13 08:29:45 UTC 2010

> Von: djmitche at gmail.com [mailto:djmitche at gmail.com] Im Auftrag von Dustin J.
> Mitchell
> Gesendet: Sonntag, 11. April 2010 21:18
> An: Tobias Oberstein
> Cc: Buildbot-devel at lists.sourceforge.net
> Betreff: Re: [Buildbot-devel] multi-repo support: build triggers
> On Sun, Apr 11, 2010 at 7:48 AM, Tobias Oberstein
> <tobias.oberstein at tavendo.de> wrote:
> > Benoît commented on 4) and didn't like it;) That’s fine, and though I don't
> agree with all
> > his objections, I can see valid points. After playing around with it a bit,
> I also see
> > that it might not be so cool in practice. But hey, it's just an option.
> If I recall, his objection was that this moves change filtering from
> its usual place - Schedulers - into the hook.
> I, too, think this is confusing and suboptimal.  Filtering should
> occur in one place - Schedulers.  With a little work (fileIsImportant
> or a ChangeFilter) you can already filter on commit message.  We could
> certainly expand ChangeFilter to make that easier.

Well, I think opinions might differ here once again because of different "twists".

I see BuildBot as kind of "meta-make" system which - in my twist - is to be
triggered explicitly by a developer. In this view, in the end it doesn't make
sense to have BuildBot receive all changes, and the nature of that "trigger"
is anyway more a build request, than a change. In other words: in my
situation I would prefer a "build request" interface to buildbot.

The view where BuildBot is receiving all changes and decides objectively,
independent of developer if a change is to be built or not is just 
a different kind of twist. In this case it's really the right way to
"concentrate" that decision on Schedulers.

> I suspect that doing this filtering in the hook is appealing because
> it eliminates the "visual noise" in the waterfall view.  You're right
> that this is a display issue, although I don't anticipate any changes
> to the waterfall to fix it.

You're right, that was one of my initial points. But now: see above.

> Dustin
> --
> Open Source Storage Engineer
> http://www.zmanda.com

More information about the devel mailing list