Calamares 3.3 series CI
Jan 16, 2024
This is the first of a series of posts about new things in Calamares 3.3 and how the 3.3 series is – and will be – developed. This very first installment is for developers of Calamares and describes how continuous integration (CI) works for Calamares now.
Legacy Dependency Setup
There is a script called
deploycala.py that traditionally was used
to configure a virtual machine (VM) for building Calamares. I say “traditionally” to
mean “that is no longer the case.” While having one Python script
that is easy to download is nice, it’s also a maintenance nightmare
- it has lists of packages that never get updated
- it sets up much more than just build-dependencies
- it lives in a different repository from Calamares itself
- it is not used in actual CI because that runs in Docker
deploycala.py worked well for many years in the
development style of the time, but it doesn’t fit very well any more.
It will be removed.
Current Dependency Setup
There is a collection of shell scripts in the
deps-something, which are the dependencies for
Calamares on something. The naming varies a bit. There’s one
called debian11, which is for building on Debian. It might even
work on Debian 12 (Bookworm).
Some of the scripts have been submitted by distro’s themselves. That’s mighty convenient, since it helps keep CI for that distro up-to-date. In combination with a nightly CI job, it means we can know, upstream, that things still work on a given target distro.
deps- scripts are:
- Debian, most venerable
- Ubuntu, a derivative, but also the source for e.g. Lubuntu that uses Calamares as its installer
- KDE Neon, a derivative of a derivative, but also the “upstreamiest” for things like KPMCore
- openSUSE, my personal go-to Linux, in both Qt5 and Qt6 variants
- Fedora, with Qt6 only
- KaOS, an opinionated KDE Plasma distro with a tremendous history of contributing to Calamares
- EndeavourOS, an Arch variant with a tremendous history of contributing to Calamares
That covers four of the “big five” distro families, which I think is pretty good. The scripts each do whatever makes sense for that distro, using distro tools and package managers and whatnot. I get merge requests from folks to update the scripts when things change downstream (e.g. Arch changed a lot of KDE-related package names as KDE Frameworks 6 gets closer).
Current CI Setup
Most of the
deps- scripts map directly to one of the CI workflows.
Calamares uses GitHub workflows to run nightly builds.
Those run in Docker containers which are pulled from specific
Docker images – for instance, the Fedora nightly build uses
The choice of image is, once again, driven by the community and what it
finds useful to build.
None of the CI builds produce any stored artifacts. There are no packages, no binaries. Those wouldn’t make much sense, anyway: most of the important part of Calamares is the configuration, which is what downstream needs to figure out for itself.
Aside from the nightly builds there is also one weekly workflow, which builds Calamares and Calamares-Extensions (a handful of extra modules and alternative branding configurations) in one (Debian) container. This is to ensure that the overall build isn’t broken (it was, for a long time, until one of the Arch-derivatives showed up to fix it).
How to Contribute
- Watch over the builds. They are reported in the Calamares Matrix channel.
- Keep the
- Upstream your patches.