Re: Transition to VM based CI

[Soumyadeep Ghosh]

Hello again,

So, the last time I checked the notary service, what it does is 
basically sends the artifact to a remote server, where the artifact is 
signed with a valid key that's recognisable as KDE's to validate the 
artifact as KDE's artifact in various stores. Am I explaining it correctly?


If I am right, then, I don't think that's needed for snaps. To upload a 
snap to the store, one basically needs the auth token of the KDE account 
in the snap store and pass it when uploading the snap. IIRC, till now, 
some of the vms were having this auth token embedded. Can't we replicate 
something like this?


Thanks,

Soumyadeep

On 08/07/25 00:20, Ben Cooksley wrote:
On Mon, Jul 7, 2025 at 11:55 PM Soumyadeep Ghosh 
 wrote:


Hi Ben,


Hi Soumyadeep,


This is an awesome news! I just wanted to know what would be the
problem in publishing those snaps built inside the new VM based CI.


There is currently no Notary built that supports handling the 
publishing process at this time, which is why we're unable to publish.



Thanks,
Soumyadeep Ghosh


Cheers,
Ben





 On Mon, 07 Jul 2025 17:19:14 +0530 *bcooks...@kde.org * wrote


Hi all,

I'm happy to announce that VM based CI is now in a state where
it is ready to begin making the transition into general
availability. As part of this i'm happy to advise that builds
for Snaps (but not their publishing) are also becoming
generally available, and FreeBSD will be updating to Qt 6.9 as
well.

This transition will also mark the general retirement of
Docker based CI, with Docker functionality only being retained
for website builds and linter jobs (such as xml-lint,
cppcheck, etc).

As part of this support for Qt 5 (except for general Linux) is
also being retired. This includes all FreeBSD and Windows
support, as well as all binary support (Appimages, Windows
exes, etc)

_Steps you need to take:_

If you only inherit the templates from sysadmin/ci-utilities,
and do not have custom jobs, then no action is needed on your
part.

If you have custom jobs which are based on the templates
currently in sysadmin/ci-utilities then  you should examine
the diff in
https://invent.kde.org/sysadmin/ci-utilities/-/merge_requests/507
to ensure that no changes are needed to your job.

Custom jobs not based on the sysadmin provided templates
likely do not need to be changed.

Projects that are Qt 5 based should remove includes for
everything except Linux general (linux.yml) as those templates
will be removed as part of this roll out.

_Timeline for the transition:_

Over the next week the first node (node6.ci.kde.org
) will be taken out of rotation for
running existing container based jobs to facilitate testing of
the automated deployment. Once this has been validated, the
conversion of the remaining nodes (node2, node3, node4, node5)
will be scheduled - converting them all to be VM based CI runners.

To allow for final legacy jobs to be completed, node1 will be
left to run remaining legacy jobs for a period of time (to be
determined). Once that finishes up, that node will also be
converted.

As part of this the dedicated VM runners currently supplied
for building KDE Linux and Snaps will also be retired. Support
for Yocto builds is out of scope for this transition at this
time but that may be re-evaluated in the future.

_What specs will the VMs be provided with?_

By default builds will be provided with 8 vCPU cores, 16GB RAM
and 200GB of disk space, although some of that disk space will
be occupied by the VM OS, development tools, etc.
Builds requiring additional resources should file a Sysadmin
ticket.

VMs will have a shared mount provided from the host at /mnt
that allows for artifacts to be cached between builds on that
node. This is mainly intended to be used for caching
dependencies and other downloaded artifacts and should not be
relied on to transfer results between jobs (as there is no
guarantee contents won't go away, or that jobs will be
allocated to the same build node).

_What benefits will we get as part of this change?_

For Linux based builds, as these are now running in a fully
fledged system, anything that depends on system level services
(like CUPS or systemd/logind) or which needs to undertake
actions normally restricted in a Docker/Podman container (like
manipulating FUSE mounts or interacting with hardware like a
TPM) should now be able to be unit tested.

For FreeBSD based builds, these ima

Re: Transition to VM based CI

[Ingo Klöcker]

On Montag, 7. Juli 2025 18:17:37 Mitteleuropäische Sommerzeit Milian Wolff 
wrote:
> Are the base VM images built using Ansible or something and thus available
> to interested developers too as a means to get quickly into a dev setup?
> Especially for Windows that would be great to have, but it would also be
> cool if one could download a VM image, start it, maybe install some editor
> of choice, and start hacking right away.

Regarding the Windows VM, if I remember correctly, Ben mentioned somewhere (I 
couldn't find it in a previous email) that you need to provide your own Windows 
license if you want to use the Windows VM.

Regards,
Ingo


signature.asc
Description: This is a digitally signed message part.