Re: [libvirt PATCH 4/5] gitlab: add several native CI jobs
On Mon, Mar 23, 2020 at 04:00:17PM +0100, Andrea Bolognani wrote:
On Fri, 2020-03-20 at 17:44 +0000, Daniel P. Berrangé wrote:
> On Fri, Mar 20, 2020 at 06:13:13PM +0100, Andrea Bolognani wrote:
> > On Tue, 2020-03-10 at 10:09 +0000, Daniel P. Berrangé wrote:
> > > With GitLab CI aiming to replace Jenkins and Travis for CI purposes, we
> > > need to expand the coverage to include native builds. This patch adds
> > > all the jobs currently run in Travis. Compared to Jenkins we obviously
> > > miss the FreeBSD jobs, but also Debian 10 and Fedora 30, but we gain the
> > > Ubuntu 1804 job as a substitute for Debian.
> >
> > Once again, two questions:
> >
> > * why are we replicating the jobs that already exist in Travis
> > CI? I get it that we eventually want to move everything over to
> > GitLab CI, but for the time being it looks like we're not really
> > gaining anything from culling jobs - we're just significantly
> > reducing our test coverage;
> >
> > * what's the endgame here? Are we going to rely solely on the
> > runners that GitLab provides for free, or are we going to plug
> > our own runners into the infrastructure? Because the former
> > would severely limit our test coverage, and bring it down to a
> > much, much worse state than what we currently have.
>
> The goal is to consolidate everything onto GitLab CI so that we have
> a single source of truth for people to look at to determine build
> status. IOW, the end game is to eliminate both Jenkins and Travis.
>
> The only technical gaps that GitLab has compared to our current
> platforms are FreeBSD and macOS. Linux coverage is fine since it
> can run arbitrary containers.
But we are limited in the number of containers we can run for
each build.
> For FreeBSD we have virtual hardware we can use to provide custom
> runners for GitLab to enable use of VMs with FreeBSD installs.
Since we're going to need a FreeBSD machine configured as a GitLab
runner, wouldn't it make sense for us to also create one or more
Linux machines that would run jobs on behalf of GitLab CI? That way
we'd remove the limitation on the number of containers we can have
running at the same time, and still have everything controlled by
GitLab.
It is bit more complicated. Custom GitLab runners are associated with
a project (and its git repos). Those runners will be used for any CI jobs
run in the context of repositories owned by that project. Obviously this
covers post-merge build jobs, or regularly scheduled build jobs.
It gets more interesting with merge requests though, because in a normal
project, the merge request is not being submmitted from a branch on the
main repo, instead it is submitted from a branch on the user's forked
repo copy. As such the CI jobs for the merge request run in the contxt
of the forked repo and do not have access to the customer runners owned
by the project.
This is a intentional security restriction to prevent denial of service
from arbitrary users from submitting (malicious) pull requests that
trigger builds on 3rd party runners.
Thus, we want to maximise the amount of build coverage we get on the
shared runners, as this is what merge requests will be using, and what
contributors will be using for tests before submitting code for review.
We'll have custom runners for providing coverage of platforms where
containers aren't viable (non-Linux), as well as providing additional
capacity.
We can selectively grant access to the custom runners to regular
contributors (whom we trust and would benefit from broader access), but
we canot make them freely available to everyone by default.
There's gitlab RFEs about making custom runners more flexible, while still
avoiding the security issues. For example, by allowing a project maintainer
to explicitly approve CI start for a merge request. No ETA for this though.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|