Jordan Petridis has been kicking ass by overhauling librsvg's continous integration (CI) pipeline. Take a look at this beauty:
On every push, we run the Test stage. This is a quick compilation
on a Fedora container that runs "make check" and ensures that the
test suite passes.
We have a Lint stage which can be run manually. This runs cargo
clippy to get Rust lints (check the style of Rust idioms), and cargo
fmt to check indentation and code style and such.
We have a Distro_test stage which I think will be scheduled weekly, using Gitlab's Schedules feature, to check that the tests pass on three major Linux distros. Recently we had trouble with different rendering due to differences in Freetype versions, which broke the tests (ahem, likely because I hadn't updated my Freetype in a while and distros were already using a newer one); these distro tests are intended to catch that.
Finally, we have a Rustc_test stage. The various crates that librsvg depends on have different minimum versions for the Rust compiler. These tests are intended to show when updating a dependency changes the minimum Rust version on which librsvg would compile. We don't have a policy yet for "how far from $newest" we should always work on, and it would be good to get input from distros on this. I think these Rust tests will be scheduled weekly as well.
Jordan has been experimenting with the pipeline's stages and the
distro-specific idiosyncrasies for each build. This pipeline depends
on some custom-built container images that already have
librsvg's dependencies installed. These images are built weekly in
gitlab.com, so every week gitlab.gnome.org gets fresh images for
librsvg's CI pipelines. Once image registries are enabled in
gitlab.gnome.org, we should be able to regenerate the container
images locally without depending on an external service.
With the pre-built images, and caching of Rust artifacts, Jordan was able to reduce the time for the "test on every commit" builds from around 20 minutes, to little under 4 minutes in the current iteration. This will get even faster if the builds start using ccache and parallel builds from GNU make.
Currently we have a problem in that tests are failing on 32-bit builds, and haven't had a chance to investigate the root cause. Hopefully we can add 32-bit jobs to the CI pipeline to catch this breakage as soon as possible.
Having all these container images built for the CI infrastructure also means that it will be easy for people to set up a development environment for librsvg, even though we have better instructions now thanks to Jordan. I haven't investigated setting up a Flatpak-based environment; this would be nice to have as well.