CI system for PR builds (was: Re: Changing default cxx_stdlib to libc++)

[db]

On 14 Mar 2018, at 04:08, Ryan Schmidt <ryandesign at macports.org> wrote:
> I was not aware of the existence of GitLab CI, but I haven't done a survey of CI systems, mainly because we already selected one many years ago: Buildbot.

GitLab CI is now integrated in GitLab, but AFAIK doesn't integrate with GitHub right now unless you mirror from it. There was an issue open to support it.


> The problem, to my mind, was not that of selecting which CI system to use, but the fact that we want to have a virtual machine template that the CI system should clone, boot up, run a job in, and then delete, or even multiple templates, one for each OS version we want to test.

> But out Buildbot VMs run on VMware ESXi, so if I were to add builds for PRs to the system, I would of course want to continue using VMware.

> We also have the problem of what exactly to put on the VM templates, and how to keep them updated.

Have you considered vagrant? It can use ESXi as hypervisor (provider) and you can provision your machines with a shell script in a var or use ansible to maintain your versions updated.


> But one of the reasons why our Buildbot setup is as fast as it is is that each Buildbot worker keeps previously-built ports installed (but inactive).

> We could pre-populate the VM templates with lots of installed but inactive ports, but in addition to making the templates and their clone(s) take up more disk space, which is at a premium, the installed ports would quickly become outdated as port updates are committed. We would need a mechanism for updating the ports installed on the templates fairly frequently.

That shouldn't happen if every update triggers the CI, right? Otherwise, you could make the machines sync to the packages public server for the distributable, and to a private server for the non-distributable binaries.