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

[Daniel P. Berrangé]

On Mon, Mar 23, 2020 at 03:35:03PM +0100, Andrea Bolognani wrote:
> 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?

This isn't a desirable approach, because in general you're not
going to be sharing the git checkout between build jobs in the
pipeline. You can selectively publish data from one stage to
another, but we don't really want to publish the entire build
dir output, which is what would be required to split off the
build & check stages.

The main benefit for having them separate is to make it easier
to view the logs to see what part failed.

GitLab has a mechanism for publishing artifacts, and the GNOME
projects use this to publish their unit tests results in junit
format IIUC. If we can get something like this wired up then we
can solve the problem if making it easy to view test failures
as a distinct thing from general build failures.

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 :|