On = Sat, Feb 24, 2024 at 8:37=E2=80=AFPM Konstantin Kharlamov <Hi-Angel@yandex.ru> wrote:

On Sat, 2024-02-24 at 16:31 +1300, Ben Cooksley wrote:=
On Fri, = Feb 23, 2024 at 11:12=E2=80=AFPM Sune Vuorela <nospam@vuorela.dk> wrote:
On 2024-02-22, Nate= Graham <nate@kde.org<= /a>> wrote:
> I've started pondering post-megarelease projects. We= 've spent so long on
> porting and bugfixing that I think it might b= e useful to shift gears to
> feature work, and I'd like to brainstor= m potential large-scale projects
> and gauge the level of interest i= n putting resources into them soon.

A bit more from the d= evops end that I'd love to see people tackle:

- Ens= ure frameworks and app unit tests interacting with windows can run
= ; on Windows.
More details: The following fails on ou= r 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 wi= ndows, but we can't
actually have passing tests in our CI.<= br>

This unfortunately= will not be easy to solve.

One of the key t= hings that we've learned out of doing CI, as has been showcased by Fre= eBSD in particular, is that the builders need to be ephemeral - that is onl= y around for the build in question that is being run.
We're curre= ntly 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.

<= /div>
For Windows however, Microsoft has limited the container stack to= not allow anything GUI related to work. The underlying libraries may be th= ere, 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.
Usa= ge 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=E2=80=A6 If Windows native= containers have so many restrictions, why not just use Linux containers wi= th WINE inside?

Becau= se Wine is not Windows either, and there could be subtle differences in how= things run / interact with the system.

Plus some of our software= would like to test certain system level infrastructure (like say KDE Conne= ct).