On 3 April 2018 at 13:09, Rainer Müller wrote: > On 2018-04-03 12:31, db wrote: >> On 3 Apr 2018, at 02:20, Rainer Müller wrote: >>> Then please explain what this would offer us at all? >> >> I'll try. GitLab let's you have external runners >> (https://docs.gitlab.com/ee/ci/runners/README.html), while TravisCI offers a >> certain amount of pipeline minutes and only supports the currently supported >> macOS versions (AFAIK from what others posted not long ago on the subject). >> Now, since version 10.6 you can use an external repo hosted on GitHub >> (https://about.gitlab.com/2018/03/22/gitlab-10-6-released/#gitlab-cicd-for-external-repos). >> And once a build succeeds, I guess it's also deliverable, whereas I'm not >> sure it's now the case. > > As far as I understood it, gitlab-runner can be installed on a machine > and is then able to spawn VMs on-demand with snapshots with an executor > (docker, virtualbox, parallels, ...). The VM image also has to have > gitlab-runner installed. > > But what exactly do you think would be the benefit from such a > complicated setup (GitHub -> GitLab -> External Runner)? > > We can already trigger our Buildbot directly from GitHub and could spawn > a VM from a snapshot using libvirt.
My (potentially wrong) impression was that libvirt only works: - from 10.11 on - with a bit of legal questionability > In any case, the the same amount of > work is required to prepare the VM image, just with different software > in it. My point exactly. I do welcome such an addition from GitLab, but it doesn't really help with our requirement of having macOS available to do the builds. The added benefit that Travis brings us is that we don't need to worry about security. If we need to implement that (non-trivial part of) functionality ourselves anyway and provide all the hardware, then GitLab does not really bring anything: the same can just as well be done in buildbot and also more closely correspond to what we use for final builds. Mojca
