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