Re: [libvirt PATCH 1/5] gitlab: use CI for building website contents
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