[libvirt] [jenkins-ci PATCH 0/1] jenkins: Start building on Ubuntu

Andrea Bolognani abologna at redhat.com
Tue Dec 10 13:54:22 UTC 2019


This patch is intended to start a slightly larger discussion about
our plans for the CentOS CI environment going forward.

At the moment, we have active builders for

  CentOS 7
  Debian 9
  Debian 10
  Fedora 30
  Fedora 31
  Fedora Rawhide
  FreeBSD 11
  FreeBSD 12

but we don't have builder for

  Debian sid
  FreeBSD -CURRENT
  Ubuntu 16.04
  Ubuntu 18.04

despite them being fully supported in the libvirt-jenkins-ci
repository.

This makes sense for sid and -CURRENT, since the former covers the
same "freshest Linux packages" angle that Rawhide already takes care
of and the latter is often broken and not trivial to keep updated;
both Ubuntu targets, however, should IMHO be part of the CentOS CI
environment. Hence this series :)

Moreover, we're in the process of adding

  CentOS 8
  openSUSE Leap 15.1
  openSUSE Tumbleweed

as targets, of which the first two should also IMHO be added as they
would provide useful additional coverage.

The only reason why I'm even questioning whether this should be done
is capacity for the hypervisor host: the machine we're running all
builders on has

  CPUs: 8
  Memory: 32 GiB
  Storage: 450 GiB

and each of the guests is configured to use

  CPUs: 2
  Memory: 2 GiB
  Storage: 20 GiB

So while we're good, and actually have plenty of room to grow, on
the memory and storage front, we're already overcommitting our CPUs
pretty significantly, which I guess is at least part of the reason
why builds take so long.

Can we afford to add 50% more load on the machine without making it
unusable? I don't know. But I think it would be worthwhile to at
least try and see how it handles an additional 25%, which is exactly
what this series does.

In my opinion, as long as the machine can keep up with demand and not
end up in a situation where it starts accumulating backlog jobs, it's
fine if builds take longer: developers who want to run a relatively
quick smoke test before posting patches can use Travis CI or 'make
ci-check at ...' locally for the purpose, whereas the role of CentOS CI
in my eyes is to try and catch as many issues as possible after merge
so that they don't end up in a release. But I realize others might
see it differently, hence this lenghty cover letter :)

Andrea Bolognani (1):
  jenkins: Start building on Ubuntu

 jenkins/jobs/defaults.yaml            | 2 ++
 jenkins/projects/libvirt-dbus.yaml    | 1 +
 jenkins/projects/libvirt-sandbox.yaml | 2 ++
 jenkins/projects/libvirt-tck.yaml     | 2 ++
 jenkins/projects/libvirt.yaml         | 2 ++
 jenkins/projects/virt-manager.yaml    | 2 ++
 6 files changed, 11 insertions(+)

-- 
2.23.0




More information about the libvir-list mailing list