On Fri, Mar 20, 2020 at 06:07:47PM +0100, Andrea Bolognani wrote:
On Tue, 2020-03-10 at 10:09 +0000, Daniel P. Berrangé wrote:
> +# This artifact published by this job is downloaded by
libvirt.org to
> +# be deployed to the web root:
> +#
https://gitlab.com/libvirt/libvirt/-/jobs/artifacts/master/download?job=w...
> +website:
> + script:
> + - mkdir build
> + - cd build
> + - ../autogen.sh $CONFIGURE_OPTS --prefix=$(pwd)/../vroot || (cat config.log
&& exit 1)
> + - make -j $(getconf _NPROCESSORS_ONLN)
> + - make -j $(getconf _NPROCESSORS_ONLN) install
> + - cd ..
> + - mv vroot/share/doc/libvirt/html/ website
> + image: quay.io/libvirt/buildenv-libvirt-fedora-31:latest
> + variables:
> + CONFIGURE_OPTS: --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
> + artifacts:
> + expose_as: 'Website'
> + name: 'website'
> + when: on_success
> + expire_in: 30 days
> + paths:
> + - website
The overall idea of building the website as a CI job is a reasonable
one, especially because it will allow us to stop periodically
speding time convincing libvirt to build just enough on what has long
been an unsupported target.
A couple of more technical questions:
* 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.
* as a follow up, why would this be a separate job? We are always
going to build the website on one of our supported targets, so
basically we end up building it twice...
Can't we just generate the artifact as a side-effect of the regular
Fedora 31 build?
The other jobs run "distcheck" for building, and as such the built
artifacts are all deleted upon success, as its all internal to the
distcheck target.
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.
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.
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 :|