This is aimed at all developers of libraries that target all supported platforms (which traditionally is the server ecosystem). At Vapor we're seeing more and more requests for running Vapor applications directly Windows and there are a number of packages being developed both established and well adopted (Swift Collections, Algorithms, Swift Log etc) and new packages being developed, like WebAuthn, where we use the Swift.org CI.
This currently presents a problem as there's no way to run CI on Windows to a) ensure they currently work and b) ensure they continue to work with new PRs, refactors and changes.
What's required to allow us to start using Windows in CI for all these packages?
OpenCombine has a CI for Windows Platform which use "compnerd/gha-setup-swift@main".
Yes, I think it would be nice to ensure for more packages that they work on Windows, and also for the Swift package index to embrace that...
Some packages seem to compile on Windows 11 but not on Windows 10 (this is a bit speculative at this point, but there is a number of indications), and some CI pipelines e.g. on GitHub only run on a Windows 10 server version. This is maybe not issue for that long, since the EOL of Windows 10 is October 2025, but nevertheless..
For server applications note that SwiftNIO does not run on Windows yet – maybe someone who knows more about it can give an estimate of how far away we are from it?
My understanding is that Windows CI is a big blocker because even if there's a load of work done to provide a Windows transport, there's nothing to stop it breaking in the future and to check it hasn't broken (which has been a problem in previous attempts)
GitHub actions aren't currently an option for repos that use the Swift CI unfortunately
Is there a thread or document which describes the current state or plan? I've ported a few ObjC servers to Windows in the past, and that wasn't actually that complicated.
Is it because native Windows things should be used instead of just winsock2?
Also, the requests you get, is that for deployment or development?
For NIO? I have no idea I'm afraid, outside my area.
And it's a mixture of development and deployment for Windows, primarily development though
NIO on Windows would indeed be quite epic. We are planning on porting over an app to Windows, but the absence of NIO is currently a blocker.
Is this for GRPC stuff, or why do you need NIO in an app (I'm also asking because I don't know the kqueue situation on Windows, that might be difficult, vs just have a simple poll()/select() loop, which might be sufficient for small scale as in apps or development).
Adding support for Windows networking in NIO orthogonal to the topic of CI here or rather having a Windows CI solution is a requirement to add Windows networking support to NIO. If we were to add this without CI we will regress this almost immediately. So in my personal opinion let’s focus this thread on the overarching CI problem across the package ecosystem instead of talking about what NIO has to do.
indeed it could be done differently, but there is a core that's already running on Linux… so . Portability of code is a big selling point.
Sry for going off topic
The people from The Browser Company have CI pipelines on Windows for their Swift based product running, even doing automated GUI testing. Maybe they can be of help.
But one question: Is this about technical issues or not having suitable servers available for this task?