[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