<div dir="ltr"><div dir="ltr">On Mon, Jun 30, 2025 at 8:42 AM Albert Vaca Cintora <<a href="mailto:albertvaka@gmail.com">albertvaka@gmail.com</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"><div dir="ltr">What will be the procedure if we ever need to add a dependency now? With Docker it was easy because we could just edit the Dockerfile. What will be the equivalent?</div></blockquote><div><br></div><div>This is still being managed through sysadmin/ci-images, which now contains everything needed to build the VM templates.</div><div>Much like with the Docker setup, there is a folder still for each VM image which contains the logic for that particular image.</div><div><br></div><div>If you look in each folder there you'll see various scripts which are used to perform the build - with all except for Windows having two common entry points of "build.sh" and "sysprep.sh".</div><div><br></div><div>These two entry point scripts are executed by sudo / as root within the VM image - with build.sh essentially being the new "Dockerfile". If you need to bring files in like patches or other scripts, for all OSes (except Windows) they can be simply placed in that folder and will become available at /var/lib/ci-files/ within the VM. I'd suggest looking at flatpak-builder / alpine-qt68 as examples of how this is used.</div><div><br></div><div>The CI jobs in the sysadmin/ci-images repository are still used to build and publish images in a fully automated fashion.</div><div><br></div><div>For those wondering how this works, in sysadmin/ci-images you'll find a utility "vm-runner" which is used for fetching images as well as provisioning and tearing down VMs based on those images (or any other qcow2 disk image you happen to have locally). It can be run on any system that has a functioning libvirt instance and KVM setup, which most distributions should provide - so you can run anything the CI system runs on your local system with minimal effort.</div><div><br></div><div>For Linux and FreeBSD vm-runner works by leveraging cloud-init to configure the system, which allows it to set a hostname, ensure the disk is fully expanded, provision user accounts for access, etc. You can see what the default templates do by looking in vm-runner/templates/. Among other things this includes dropping the files from those folders in sysadmin/ci-images into the image (which is what the --cloudinit-resources flag to vm-runner run triggers).</div><div><br></div><div>To build an image all we do (for Linux/FreeBSD at least) is:</div><div>a) Download a cloud-init enabled image for the distribution in question</div><div>b) Boot that image using vm-runner, passing in the resources from the sysadmin/ci-images folder for the image being built</div><div>c) Via SSH, run the build.sh script within the VM (using sudo to give it root privileges)</div><div>d) Via SSH, run the sysprep.sh script within the VM (once again using sudo)</div><div>e) Once the VM has shutdown, upload it to <a href="http://storage.kde.org/vm-images/">storage.kde.org/vm-images/</a> for use by VM based CI builds / vm-runner clients run elsewhere.</div><div><br></div><div>Developers are more than welcome to use vm-runner locally should they wish to. It's requirements are pretty light (ignoring the VM specs you specify) and i've been using it on my local system while developing this setup (and it actually makes some sysadmin tasks easier by letting me quickly spin up VMs to test things in). The images used by the CI system live at <a href="http://storage.kde.org/vm-images/">storage.kde.org/vm-images/</a> and should be specified without the .qcow2 extension.</div><div><br></div><div>If I want to run an Alpine CI image locally for instance i'd run:</div><div><span style="font-family:monospace"><span style="color:rgb(0,0,0)">vm-runner run --cpu 4 --ram 8G --disk 100G --image <a href="http://storage.kde.org/vm-images/alpine-qt68">storage.kde.org/vm-images/alpine-qt68</a> --pull --mount ~/shared/ --ssh-keys ~/.ssh/id_ed25519.pub myalpineci</span><br></span></div><div><br></div><div>Once booted it will advise me of the IP address and I can login by doing a relatively standard ssh user@$IP to obtain a shell - with ~/shared/ from my host system mounted at /mnt in the VM. Note that shared mounts don't currently work for FreeBSD due to missing drivers on the FreeBSD side - I believe those are in review for FreeBSD 15.0 currently.</div><div><br></div><div>Hope that illustrates things a bit.</div><div><br></div><div>Cheers,</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><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Jun 28, 2025 at 1:23 PM Ben Cooksley <<a href="mailto:bcooksley@kde.org" target="_blank">bcooksley@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi all,<div><br></div><div>As part of our transition to VM based CI, i'm about to start cutting over the build infrastructure for the underlying images used to support our CI system from the current Docker model to the new VM based model.</div><div><br></div><div>This follows the successful on-infrastructure build of a Windows image completed this evening, which was the last milestone component remaining to be validated when it came to building images.</div><div><br></div><div>Because the system will continue to rely on the Docker images for a period of time while we're transitioning over the next week or two, we will temporarily be unable to add, update or remove any system level dependencies (including Qt) during this time period.</div><div><br></div><div>More information on the transition will be published in the coming week once the images have been ported over, all successfully built, and a variety of test builds have been successfully accomplished using them.</div><div><br></div><div>I'm anticipating the completion of migration to VM based CI to be completed within the next 2 weeks, if not sooner.</div><div><br></div><div>Thanks,</div><div>Ben</div></div>
</blockquote></div>
</blockquote></div></div>