[libvirt PATCH 4/5] gitlab: add several native CI jobs

Tue Mar 24 16:15:38 UTC 2020

On Tue, Mar 24, 2020 at 04:41:20PM +0100, Andrea Bolognani wrote:
> On Mon, 2020-03-23 at 15:16 +0000, Daniel P. Berrangé wrote:
> > On Mon, Mar 23, 2020 at 04:00:17PM +0100, Andrea Bolognani wrote:
> > > 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.
> 
> Where is this documented? I've been looking through the gitlab-runner
> documentation but I haven't been able to find anything about this.

It isn't clearly documented anywhere, but you can see it in practice
quite easily. Fork a project, and open a merge request. You'll see
the pipelines are reported against your fork, and not against the
original repo. Your fork won't have access to anything except the
standard shared runners.

> > 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.
> 
> It should be possible to prevent a DoS by configuring a limit on the
> number of concurrent jobs that are allowed for the runner (see [1]),
> so this looks like a moot point.
> 
> As for running the build jobs securely, the Docker executor should
> take care of that when it comes to Linux; for FreeBSD, I think we'd
> have to use a custom executor that drops privileges instead, because
> Docker is not a possibility there.

That's all fine, but there's nothing we cna do about it. This is not
a restriction we have the ability to relax, as it is policy set by
the GitLab CI infra on runner usage.

> > 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.
> 
> I don't understand how this would work. If the CI configuration
> contains say 20 jobs, 18 of which are to be run on Linux and the
> remaining two are for FreeBSD, and the shared runners are limited to
> 10 jobs per build, how would GitLab decide which 10 jobs to ignore
> when testing a merge request?

I don't know what settings you're referring to, but there's no
hard limit on total job count on the shared runners. There is
some limit on the concurrent jobs for fairness between users, so
further jobs merely have to wait for the previous jobs to complete,
just as we see with Travis.

  https://docs.gitlab.com/ee/ci/runners/README.html#how-shared-runners-pick-jobs

> > 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.
> 
> Can you please point me to the relevant documentation?

There are some docs here, but they're not comprehensive:

   https://docs.gitlab.com/ee/ci/runners/README.html

> > 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.
> 
> Do you have links to these RFEs handy?

I don't have the links handy any more, as this was a few weeks back, and
anyway we need to set things up with what exists today, not what might
exist in future. 

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 :|