[152490] contrib/buildbot-test

[Ryan Schmidt]

> On Oct 20, 2016, at 5:24 PM, Lawrence Velázquez <larryv at macports.org> wrote:
> 
>> On Sep 12, 2016, at 9:06 PM, Ryan Schmidt <ryandesign at macports.org> wrote:
>> 
>>> On Sep 12, 2016, at 7:46 AM, Rainer Müller <raimue at macports.org> wrote:
>>> 
>>>> On 2016-09-12 04:17, Ryan Schmidt wrote:
>>>> 
>>>> There are currently too many places in master.cfg that have
>>>> knowledge of which worker runs on which platform. I'd like to get
>>>> all of that information confined to the config file.
>>> 
>>> This list would be based on OS X installations, not on the function
>>> the buildslaves serve.
>> 
>> Ok, then it could be inverted, with the top-level keys being base,
>> ports, ...
>> 
>>> Maybe we should split the list of builders between those tied to
>>> a machine and those that could run anywhere?
>>> 
>>> My intention was that the builders "docs-guide" and "docs-www" can
>>> use the same slave. I do not see a need to use separate buildslave
>>> instances for them. That will make it easier to just add new
>>> builders for more tasks (for example portindex2sql or generating
>>> a web version of our port help/man pages).
> 
> What about something like this? Array values could be understood to
> represent a list of suffixes that would be used to dynamically generate
> buildslave names, while string values would simply be the name of the
> buildslave to use.
> 
> {
> 	"base": [
> 		"-10.5_ppc",
> 		"-10.6_i386",
> 		"-10.6_x86_64",
> 		"-10.7_x86_64",
> 		"-10.8_x86_64",
> 		"-10.9_x86_64",
> 		"-10.10_x86_64",
> 		"-10.11_x86_64",
> 		"-10.12_x86_64"
> 	],
> 	"ports": [
> 		"-10.5_ppc", "-10.5_ppc_legacy",
> 		"-10.6_i386", "-10.6_i386_legacy",
> 		"-10.6_x86_64", "-10.6_x86_64_legacy",
> 		"-10.7_x86_64", "-10.7_x86_64_legacy",
> 		"-10.8_x86_64", "-10.8_x86_64_legacy",
> 		"-10.9_x86_64",
> 		"-10.10_x86_64",
> 		"-10.11_x86_64",
> 		"-10.12_x86_64"
> 	],
> 	"docs-guide": "base-10.12_x86_64",
> 	"docs-www": "base-10.12_x86_64"
> }
> 
> (I'm bringing this up again because I'm working on the Buildbot
> configuration, and it would be nice to remove some of the code that
> knows too much about builder/buildslave names.)
> 
> vq

That looks plausible, thanks.

Are the passwords then a separate entry?

I had planned to put the guide-building and www-fetching and ports-sql-updating and distfiles-fetching and rsync-server-updating tasks on the buildbot master, rather than on any of the existing buildbot workers that are building ports and base, because the existing workers are often quite busy, while the master is just sitting there doing largely nothing.