[152630] contrib/buildbot-test

[Ryan Schmidt]

> On Sep 14, 2016, at 2:01 PM, Rainer Müller <raimue at macports.org> wrote:
> 
> 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"?

I like that. Or we could call it "steve".


> 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.

The master uses MacPorts in /opt/local for its own software (nginx, buildbot, rsync, etc.). I can manually install anything else there that we need. It's probably not best to automate selfupdating that MacPorts install, but it can have its own install in another prefix that it selfupdates. Giving the buildbot user sudoers access to that port command seems fine.