On Sat, 2024-02-24 at 16:31 +1300, Ben Cooksley wrote: > On Fri, Feb 23, 2024 at 11:12 PM Sune Vuorela <nos...@vuorela.dk> > wrote: > > On 2024-02-22, Nate Graham <n...@kde.org> wrote: > > > I've started pondering post-megarelease projects. We've spent so > > long on > > > porting and bugfixing that I think it might be useful to shift > > gears to > > > feature work, and I'd like to brainstorm potential large-scale > > projects > > > and gauge the level of interest in putting resources into them > > soon. > > > > A bit more from the devops end that I'd love to see people tackle: > > > > - Ensure frameworks and app unit tests interacting with windows > > can run > > on Windows. > > More details: The following fails on our windows CI > > > > https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp > > I find it weird that we are spending resources on putting things > > in > > the windows store and making apps available on windows, but we > > can't > > actually have passing tests in our CI. > > > > > This unfortunately will not be easy to solve. > > One of the key things that we've learned out of doing CI, as has been > showcased by FreeBSD in particular, is that the builders need to be > ephemeral - that is only around for the build in question that is > being run. > We're currently accomplishing this by using containers - via Podman > (for Linux/Android/FreeBSD) and Docker (for Windows). > > Containers also offer us the advantage of allowing people to easily > reproduce the CI environment on their local system without too much > trouble. > > For Windows however, Microsoft has limited the container stack to not > allow anything GUI related to work. The underlying libraries may be > there, but the equivalent display server components are not > operational. > > To complicate things further, on Windows certain permissions are > restricted to the interactive console and are not possible to do as > either a scheduled task or as a system service. > Usage of existing Windows automation frameworks such as Powershell > Remoting or SSH will therefore not work if we want things to > perfectly replicate a end user environment - because those will run > the command(s) as part of a non-interactive session (even if the user > we connect as is the same one logged in on the desktop console).
Idk if it's a silly question, but… If Windows native containers have so many restrictions, why not just use Linux containers with WINE inside?