Build hardware resources

[Mojca Miklavec]

Ryan,

On 15 March 2018 at 05:19, Ryan Schmidt wrote:
> On Mar 14, 2018, at 07:23, db wrote:
>> On 14 Mar 2018, at 01:14, Rainer Müller wrote:
>>> Are you going to sponsor a dedicated Mac server for GitLab CI?
>>> Travis CI is available at no cost and we have no funds to pay for anything.
>>
>> If MacPorts is short on resources, these could be listed on the website. Folks can certainly ask around.
>
> We did have an offer on the list some months ago from someone with spare Mac hardware in a data center that they would let us use. We did not respond to the offer. I'm not sure how comfortable I am accepting unsolicited infrastructure offers from unfamiliar parties.

I would make a clear distinction between:
- official signed builds distributed to the users
- unofficial test builds that don't get distributed anywhere

The first category of builds needs to be carefully monitored and this
is the case now.

But I would be a lot more flexible about the second category. I can
imagine that people might be willing to provide resources for building
under various exotic configurations.

Let's assume that someone offers enough resources to set up builders
for 10.4 all the way up to 10.13 for all available architectures and
possibly even using multiple configurations (say, to set up gcc7 as
default compiler on some of those platforms).

And assume that someone would sit down and write the necessary code to
spawn new virtual machines for each pull request on all those systems.
The binaries would not get distributed anywhere, we would only get
feedback about whether the build succeeded or not.

I don't see why having such build machines under someone else's
administration would be problematic. Travis has the limitation that
one cannot test whether a patch fixes a build on < 10.9, or to check
the impact of, say, switching 1000+ ports from perl5.x to perl5.(x+2),
while such a setup would allow that.

Now, yes, we are currently short both on hardware and human/software
resources at the moment. I'm pretty sure that there is a way to get
some hardware resources sponsored / donated by users, but of course
that only makes sense if we know exactly what to do with them. If
someone writes all the necessary code to use Buildbot's built-in
capabilities of starting a new VM per build, we could certainly deploy
that somewhere.

(Also, if someone is willing to write a few hundreds or thousand lines
of good quality code for any other CI tool, I would not really mind if
that's not precisely buildbot. It would of course make more sense to
have the same setup, but if someone else does all the work, I would
not impose a limiting factor on that.)

So: if we get both software and hardware capabilities in place, this
would certainly be welcome and I don't see any problem with that even
if the hardware resides at exotic/unknown locations. I would of course
keep the build master for such builds well-separated from the official
build master that generates the official packages.

In summary, about 3th party builders:

- If we want to test new commits only (on some more exotic platforms),
testing on 3th party builders should be trivial to set up, but most
likely doesn't add that much added value, except for perhaps some
preliminary overview of problems we might face when we switch to
libc++ etc.

- If we want to test pull requests, that would provide a lot of added
value, but someone would need to write the code to do it properly.


To db: it's definitely not as easy as writing three lines of code into
.travis.yml though, even if we had the hardware resources.

Mojca