<div dir="ltr"><div dir="ltr">On Tue, Jun 3, 2025 at 9:03 AM Albert Astals Cid <<a href="mailto:aacid@kde.org">aacid@kde.org</a>> wrote:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">El dilluns, 2 de juny del 2025, a les 13:39:21 (Hora d’estiu d’Europa <br>
central), Ben Cooksley va escriure:<br>
> Hi all,<br>
> <br>
> For some time now we have had a variety of issues with our Docker/Podman<br>
> based CI builds. These have included the lack of GUI test support on<br>
> Windows, periodic crashes on FreeBSD, poor IO performance of Windows<br>
> builds, issues supporting builds for Flatpak and Snaps and inability to<br>
> support either builds or tests where elevated privileges or system session<br>
> resources are needed.<br>
> <br>
> In addition to this we've had issues where Linux CI builds have the<br>
> capability to trigger OOM events on the CI hosts, which in turn takes out<br>
> Windows and (less often) FreeBSD builders. While this does not occur too<br>
> often, it does happen from time to time and eventually negatively impacts<br>
> the build queue for those platforms.<br>
> <br>
> The need to have dedicated VMs for FreeBSD and Windows on our builders also<br>
> makes setting up of a CI build node for KDE software a more complicated and<br>
> time intensive task than it otherwise needs to be (and means that the<br>
> amount of systems to care for increases by 3 for every CI node we add).<br>
> <br>
> While individually relatively minor, together these issues more than<br>
> justify making a significant change to the way we run our CI system - in<br>
> this case transitioning from container based builds to VM based builds.<br>
> <br>
> These builds will still take place on dedicated hardware that we control,<br>
> however instead of taking place within a container (managed by Podman on<br>
> Linux and FreeBSD, or Docker on Windows) they will instead take place<br>
> within a VM using a copy-on-write disk image.<br>
> VM based builds will unfortunately take a little longer to start (it takes<br>
> ~10 seconds for a VM from any of Linux, FreeBSD or Windows to boot on my<br>
> personal system) however the benefits we gain should more than outweigh<br>
> this small downside.<br>
> <br>
> This has been under development for the past couple of weeks and is now<br>
> reaching the point where the only remaining steps are to get it integrated<br>
> with the Gitlab CI agent (gitlab-runner) for which prototype code is<br>
> already in place, and complete porting of our images over. Once that<br>
> happens a complete rebuild of all of our builders will be swiftly<br>
> undertaken to transition them completely over to the new VM based<br>
> infrastructure.<br>
> <br>
> Specs wise, at this time it is planned for each spawned standard VM to be<br>
> provided with 2/3's of the system CPU cores (so 12 cores), 16GB RAM and<br>
> 100GB of disk space (although some of that will be occupied by the system<br>
> image - approximately 10GB for standard Linux builds and ~30GB or so for<br>
> Windows builds). There will be a higher resource tier available for certain<br>
> builds however that will be on request only and would need to be justified<br>
> (such as Craft needing to build QtWebEngine).<br>
> <br>
> As launching VMs is not the most efficient approach for all workloads,<br>
> limited support for running Docker containers will be preserved, however<br>
> this support is primarily intended for running linters, sanity checks and<br>
> website builds, and is not intended for running general CI/CD builds.<br>
> <br>
> The tooling used by the CI nodes to run VMs is something that should be<br>
> fairly trivial for people to run on their own local system should they wish<br>
> to run any of those images (say for FreeBSD or Android), although you will<br>
> need to setup libvirt yourself (SUSE has very good instructions for this,<br>
> Debian less so as their instructions lack installing the packages needed to<br>
> provide UEFI and TPM support). The tooling itself was merged this evening<br>
> to sysadmin/ci-images (vm-common/ folder) and can be used with the VM<br>
> images found at <a href="https://storage.kde.org/vm-images/" rel="noreferrer" target="_blank">https://storage.kde.org/vm-images/</a><br>
> <br>
> There is however one downside to this - Qt 5 support.<br>
> <br>
> Over the past few months distributions have been steadily removing packages<br>
> and other supporting infrastructure needed to keep Qt 5 builds alive. In<br>
> the case of Windows, support for the entire Qt 5 tree has been unmaintained<br>
> for some time. For FreeBSD and SUSE a significant number of packages have<br>
> been removed - which in the case of SUSE also includes packages needed to<br>
> support the building of KJS.  Accordingly, because builds of Frameworks are<br>
> a first stepping stone to support building anything else, it will not be<br>
> possible for us to produce Qt 5 based VM build images for any of the 3<br>
> platforms.<br>
> <br>
> We will therefore have to remove Qt 5 support from the CI system with the<br>
> transition to VM based CI.<br>
<br>
>From previous discussions I had the impression this was only for things that <br>
wanted to create packages and not for "want to have CI to compile/run tests".<br>
<br>
Can you confirm you are proposng a total annihilation of Qt5 support in our <br>
CI?<br></blockquote><div><br></div><div>At the time we had that discussion it was still possible to build some of the Qt 5 images, however that is no longer the case - all of them now fail to build.</div><div><br></div><div>In the case of the suse-qt515 image, the removal of libpcre in SUSE means it is no longer possible to build KJS.</div><div>Consequently, we're no longer able to build all Frameworks (making 'kf5' branch CI for Frameworks non-functional) so there isn't much point in looking further to support Qt 5 on Linux.</div><div><br></div><div><div>For FreeBSD the story is much the same as SUSE - packages are being removed as apps upgrade to Qt 6 and the Qt 5 version of libraries becomes surplus to requirements.</div><div></div></div><div><br></div><div>For Windows the continued operation of that CI has only been possible because our existing images are still around - new ones cannot be built.</div><div>That has been the case for a significant amount of time now, and it is not worth the investment to fix it as everyone who works on Windows has moved on to Qt 6.</div><div><br></div><div>In essence there is little we can do to keep this alive - distributions are removing support so we must follow suit.</div><div><br></div><div>The correct course of action is to accelerate the porting of the remaining applications, not to delay and keep Qt 5 alive.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Cheers,<br>
  Albert<br></blockquote><div><br></div><div>Regards,</div><div>Ben</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> <br>
> Please let me know if there are any questions on the above.<br>
> <br>
> Thanks,<br>
> Ben<br>
<br>
<br>
<br>
<br>
</blockquote></div></div>