[152630] contrib/buildbot-test

[Rainer Müller]

On 2016-09-14 16:10, Ryan Schmidt wrote:
>> +    "deploy": {
>> +        "www": {
>> +            "host": "",
>> +            "user": "",
>> +            "sshkeyfile": "",
>> +            "sshknownhostsfile": "ssh_known_hosts",
>> +            "destpath": ""
>> +        },
>> +        "guide": {
>> +            "host": "",
>> +            "user": "",
>> +            "sshkeyfile": "",
>> +            "sshknownhostsfile": "ssh_known_hosts",
>> +            "destpath": ""
>> +        }
>> +    }
>>
>>  }
> 
> I had to remove these lines when deploying because I don't have a "docs" worker set up yet.
>
> Configuration Errors:
>   builder 'docs-www' uses unknown slaves 'docs'
>   builder 'docs-guide' uses unknown slaves 'docs'

Yes, that is the right solution. The previous logic based it on the
existence of the "docs" worker, now it is controlled by the entries in
the "deploy" dict.

> This worker will run on the same server as the master. We have other tasks we need to run on the master as well: mirroring distfiles on port changes; copying ports to the rsync server on port changes; creating ports.tar on port changes; creating base.tar on base changes. Will these builders use the same worker? If so, what name could we pick (not "docs") that would be sufficiently all-encompassing?

Yes, I would put all of these tasks on the same set of workers
(let's start with just one, but if we ever get too many of these tasks,
we could add more for load balancing).

I agree this will be more than just documentation. Maybe give it a very
generic name such as "jobs"?

This worker would need the required software installed, preferably from
ports. If we want to automate port install/upgrade, we would have to run
the worker as root and drop privileges with sudo/su for the actual jobs.
An alternative solution would be to provide an existing port install and
only run 'sudo port ...' with sudoers allowing the user to run this
command without password.

Rainer