[Python-Dev] Tag-based buildmaster (was: Most 3.x buildbots are green again ... )

[Zachary Ware]

(Cross-posting to python-buildbots, discussion is probably best continued there)

On Wed, Apr 13, 2016 at 3:37 PM, Brett Cannon <brett at python.org> wrote:
> On Wed, 13 Apr 2016 at 13:17 Zachary Ware <zachary.ware+pydev at gmail.com>
> wrote:
>> After receiving a suggestion from koobs several months ago, I've been
>> intermittently thinking about completely redoing our buildmaster setup
>> such that instead of a single builder per version on each slave, we
>> instead set up a series of builders with particular 'tags', and each
>> builder attaches to each slave that satisfies the tags (running each
>> build only on the first slave available).  This would allow us to test
>> some of the rarer options (such as --without-threads) significantly
>> more often than 'never', and generally get a lot more
>> customization/flexibility of builds.  I haven't had a chance to sit
>> down and think out all the edge cases of this idea, but what do people
>> generally think of it?  I think the GitHub switchover will be a good
>> time to do this if it's generally seen as a decent idea, since there
>> will need to be some work on the buildmaster to do the switch anyway.
>
> So we have slaves connect to multiple builders who have requirements of what
> they are testing? So the --without-threads master would have all slaves able
> to compile --without-threads connect to it and then do that build? And those
> same slaves may also connect to the gcc and clang masters to do those builds
> as well? So would that mean slaves could potentially do a bunch of builds
> per change? That sounds nice to me as long as the slave maintainers are also
> up to utilizing this by double/triple/quadrupling their builds.

Basically, yes.  I'm unsure as to whether the build would be done on
all matching slaves on each change, or rotate between them (or use the
next available) on each change; that would likely come down to which
scheme we collectively want.  I also have vague ideas about having
'daily' or even 'weekly' tags for builds that are deemed to not need a
build for every changeset, which could alleviate some of the
multiplying.

-- 
Zach