We can now self hosted runners which gives us enough disk space to re-enable Windows CI (using runner name "garm-jammy-16"). However since a secret needs to be used to download the image and forks do not have access to secrets we need to decide whether to go with merge queue approach (like Cloud Hypervisor) or only test Windows after it has already been pushed to main.
@rbradford I prefer to use the merge queue approach, because we can detect a breaking change for the Windows guest boot before merging to the main branch. I'll create a GHA workflow for the Windows CI.
We can now self hosted runners which gives us enough disk space to re-enable Windows CI (using runner name "garm-jammy-16"). However since a secret needs to be used to download the image and forks do not have access to secrets we need to decide whether to go with merge queue approach (like Cloud Hypervisor) or only test Windows after it has already been pushed to main.
@retrage What would your preference be?