[libvirt PATCH 1/5] gitlab: use CI for building website contents

Andrea Bolognani abologna at redhat.com
Mon Mar 23 14:35:03 UTC 2020


On Fri, 2020-03-20 at 17:27 +0000, Daniel P. Berrangé wrote:
> On Fri, Mar 20, 2020 at 06:07:47PM +0100, Andrea Bolognani wrote:
> >   * why do we care about whether all those features are enabled or
> >     not? It's pretty ugly to have that list hardcoded in our build
> >     scripts, and I don't quite get the point in having it in the
> >     first place;
> 
> It is to reduce the build time - it cuts time for the job in 1/2
> which is worthwhile win.

On my laptop, where make is configured to use parallel builds by
default through $MAKEFLAGS:

  $ git clean -xdf && time sh -c 'mkdir build && cd build && ../autogen.sh && make && make install DESTDIR=$(pwd)/../install'

  real    2m52.997s
  user    14m46.604s
  sys     1m56.444s

  $ git clean -xdf && time sh -c 'mkdir build && cd build && ../autogen.sh --without-libvirtd --without-esx --without-hyperv --without-test --without-dtrace --without-openvz --without-vmware --without-attr --without-audit --without-blkid --without-bash-completion --without-capng --without-curl --without-dbus --without-firewalld --without-fuse --without-glusterfs --without-libiscsi --without-libssh --without-numactl --without-openwsman --without-pciaccess --without-readline --without-sanlock  --without-sasl --without-selinux --without-ssh2 --without-udev && make && make install DESTDIR=$(pwd)/../install'

  real    1m59.594s
  user    9m4.929s
  sys     1m13.152s

  $ git clean -xdf && time sh -c 'mkdir build && cd build && ../autogen.sh && make -C docs/ && make -C docs/ install DESTDIR=$(pwd)/../install'

  real    0m33.350s
  user    0m54.281s
  sys     0m10.986s

So we can basically have our cake and eat it too! :)

> Using gitlab stages for different types of builds gives us a more
> friendly output view. We can distinguish what aspect of the build
> has failed at a glance instead of having to peer into the 100's
> of KB of build logs.

Are we eventually going to have the same syntax-check / build /
check split as we currently have in Jenkins?

> Eventually we can make use of filters so that when people submit
> a patch which only touches the docs, we can skip all the native
> build and cross build jobs entirely, only running the docs stage.

Sounds like a nice little optimization, assuming we can get it to
work reliably, but I have to wonder how frequent it really is that
the documentation is updated outside of a series that touches the
code as well...

-- 
Andrea Bolognani / Red Hat / Virtualization




More information about the libvir-list mailing list