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. For FreeBSD we have virtual hardware we can use to provide custom runners for GitLab to enable use of VMs with FreeBSD installs. I'm not proposing to turn off the Linux Jenkins jobs just yet, as the sub-package chain builds still rely on that. The sub-packages will all need wiring up into GitLab CI too. Ultimately though there's nothing Jenkins does that we can't replicate in GitLab. We don't have an immediate solution for macOS due to the licensing issues around use of macOS, so Travis will unfortunately still be needed for that platform, but the remainder of jobs are not required. It might be possible to wire up a GitLab job that pushes the changes over to Travis, and pulls its build result back for macOS, so we still have a single viewing point, even if we still use Travis. This series has cut down on the number of cross-build jobs we're running, but my experience of looking at the results we've seen with them, is that they've almost never identified a bug we didn't already see with one for the other jobs. So I think it is reasonable to cut cross-build jobs down to focus on the important unique aspects - a 32-bit build and a big endian build. Overall we're not loosing any notable CI coverage with this series, and we'll gain an improved view of our results. 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 :|
