Re: [libvirt PATCH 4/5] gitlab: add several native CI jobs
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 :|