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
