On Mon, Jul 21, 2025 at 9:56 PM Dmitry Kazakov <dimul...@gmail.com> wrote:
> Hi, Ben! > > What should be the steps for transitioning Krita jobs to the new > framework? You said it will be possible to run docker images inside the new > VM. Are there any hints on how to do that? > Slight misunderstanding there. I said that it would still be possible to run Docker jobs because there would be separate runners we were going to provide for this purpose. Use of them for building software however is discouraged as they're meant for linter jobs. Trying to run a Docker image inside a VM based CI image would be an awful hack and while more than doable would be difficult to support and debug, gives up basically all the benefits of being VM based, and would be slower in general as well as more expensive for us to run resource wise. It's not something i'm going to be particularly happy about you running. For workflows where a local Docker (Linux) image is still desired it is possible for the CI system to produce both a VM image as well as a Docker image, and that is the preferred path forward. This is what we do for KDE's Android SDK. For non-Linux OSes, only VM based images are supported now and there is no possibility to build Docker/Podman images for them. As a starting point, has Krita transitioned to the 2204 based images? Cheers, Ben > > On Sun, Jul 20, 2025 at 8:44 PM Ben Cooksley <bcooks...@kde.org> wrote: > >> Hi all, >> >> Yesterday afternoon I actioned the rollout of VM based CI, which is now >> in production for all platforms. >> >> As part of this, Snap builds are now generally available and may be used >> freely. Publishing of Snaps still requires a notary to be built, so that >> component remains unavailable for now. >> The previous dedicated VM providing support for Snaps has also been >> retired. >> >> FreeBSD has also updated to Qt 6.9 as part of this changeover, and all >> other images (SUSE Qt 5.15, Qt 6.9 and Qt 6.10, Alpine Qt 6.8) have also >> been rebuilt and are fully updated as well. >> >> Builder wise, 4 of our previous 6 builders have been converted to be VM >> based. The remaining two are scheduled for retirement to allow for an ARM >> builder to be provided, and will be temporarily available for a further >> week or so to allow for old pipelines to be completed. >> The ARM builder has also been provisioned and connected as a VM based >> runner to Gitlab. >> >> Should your project be Qt 5 based still, you will find that all support >> for everything except Linux has been removed. This is in line with what was >> previously announced and you will need to remove those jobs from your CI >> configuration. >> All build artifacts relating to Qt 5 on FreeBSD and Windows have already >> been purged from the system, as support for those platforms has now ended. >> >> If your project has custom jobs, it would be advisable to check that >> those jobs are making use of VM based CI where possible, as build power on >> the Docker side following this conversion will be more limited (being >> primarily intended to support building websites and running linter checks). >> >> Should you be running custom workflows it is important to note that the >> location for caching artifacts has changed as part of this migration. It is >> no longer at /mnt/artifacts/$PLATFORM/ or /mnt/caches/$PLATFORM/ - instead >> things are now found at /mnt/$PLATFORM/artifacts/ and >> /mnt/$PLATFORM/caches/. It is imperative that this change is reflected in >> your jobs, otherwise you may encounter permission related failures due to >> different distributions having different user/group IDs. >> >> For those curious, the rollout procedure across all four machines took >> less than an hour to process (including the Hetzner re-imaging of the >> machines), and is largely fully automated. There is now also automation in >> place to clean up old images as well, which will hopefully reduce the risk >> that the builders run out of disk space. >> >> Please let me know if you have any questions. >> >> Many thanks, >> Ben >> > > > -- > Dmitry Kazakov >
