Add QEMU on Windows to CI #3475
Conversation
Another topic to check - use chocolatey to install QEMU, because msys2 QEMU installation feels slow. |
|
Probably would need to move mounts-windows under _default to not fail validation script. |
For now it will use additional templates, because of incompatible mounts. Signed-off-by: Arthur Sengileyev <arthur.sengileyev@gmail.com>
|
Chocolatey QEMU package is not well maintained, so, I chose winget instead, which is a great alternative. There is a known limitation that it is not available out of the box in Windows Server 2022, so, there is a hacky action to add it, which is now archived and will not be needed at all after migration to Windows Server 2025, this is highlighted by the comment. |
|
@jandubois @AkihiroSuda I would like to know your opinions on how reasonable is it to extend CI to support this (to not overload CI and not increase costs significantly). From my side there is no rush and I can see reasons to postpone this until #3316 is addressed (via #3318 refresh or other means). Also it might be reasonable to wait for migration to WinServer 2025 to not use now archived https://github.com/Cyberboss/install-winget action. I authored it now to have proof of concept confirmed and potentially creating reference starting point for its introduction. |
There was a problem hiding this comment.
Would it be possible to merge the template to default?
If it is still difficult, can we use base: template://default for deduplication?
There was a problem hiding this comment.
If we decide that #3318 is acceptable, then the regular template://default will just work on Windows (I think). Well, all the templates should work then, as the default mount points have been factored out now.
| - name: Make | ||
| run: make | ||
| - name: Install winget | ||
| # TODO remove this step for Windows Server 2025 based runners |
There was a problem hiding this comment.
Windows 2025 seems now available:
There was a problem hiding this comment.
I've just created a new runner type for this, so we can try it out:
There was a problem hiding this comment.
Are we sure we actually need 8 cores? Or maybe we just start with a larger runner, and try later to see how much worse it becomes to run on a standard runner?
The 4-core runner is also limited to 16GB. That is plenty on macOS; not sure what is needed on Windows.
There was a problem hiding this comment.
Why do we need to create a custom runner?
There was a problem hiding this comment.
So it becomes available in our org? Somebody must have created the windows-2022-8-cores runner too, as it is also a custom entry for the lima-vm org (I don't think it was me). CNCF has only created custom Linux runners:
There was a problem hiding this comment.
IIUC I had to create it perhaps for nested virt at that time?
Probably it should just work with the standard runner now
There was a problem hiding this comment.
About Ubuntu and Windows larger runners:
Larger runners with Ubuntu or Windows operating systems are configured in your organization or enterprise.
No additional configuration is required.
For now it will use additional templates, because of incompatible mounts.
This is probably not for 1.1.0.
It is possible to use default.yaml for Windows with changes from #3318 (this would need rebase first, but I checked it using a rebased patch in a forked repo - example run https://github.com/arixmkii/qcw/actions/runs/14681726480/job/41205771124).