[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-community
Subject:    Re: Post-MegaRelease projects
From:       Konstantin Kharlamov <Hi-Angel () yandex ! ru>
Date:       2024-02-24 7:37:20
Message-ID: 1cecabfc73d5cb4f96c9e4c66430ca2d021b6d22.camel () yandex ! ru
[Download RAW message or body]

On Sat, 2024-02-24 at 16:31 +1300, Ben Cooksley wrote:
> On Fri, Feb 23, 2024 at 11:12 PM Sune Vuorela <nospam@vuorela.dk>
> wrote:
> > On 2024-02-22, Nate Graham <nate@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?

[Attachment #3 (text/html)]

<html><head><style>pre,code,address {
  margin: 0px;
}
h1,h2,h3,h4,h5,h6 {
  margin-top: 0.2em;
  margin-bottom: 0.2em;
}
ol,ul {
  margin-top: 0em;
  margin-bottom: 0em;
}
blockquote {
  margin-top: 0em;
  margin-bottom: 0em;
}
</style></head><body><div>On Sat, 2024-02-24 at 16:31 +1300, Ben Cooksley \
wrote:</div><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf \
solid;padding-left:1ex"><div dir="ltr"><div dir="ltr">On Fri, Feb 23, 2024 at 11:12 PM Sune \
Vuorela &lt;<a href="mailto:nospam@vuorela.dk">nospam@vuorela.dk</a>&gt; wrote:<br></div><div \
class="gmail_quote"><blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf \
solid;padding-left:1ex"><div>On 2024-02-22, Nate Graham &lt;<a href="mailto:nate@kde.org" \
target="_blank">nate@kde.org</a>&gt; wrote:<br>&gt; I've started pondering post-megarelease \
projects. We've spent so long on <br>&gt; porting and bugfixing that I think it might be useful \
to shift gears to <br>&gt; feature work, and I'd like to brainstorm potential large-scale \
projects <br>&gt; and gauge the level of interest in putting resources into them \
soon.<br></div><div><br>A bit more from the devops end that I'd love to see people \
tackle:<br></div><div><br>&nbsp;- Ensure frameworks and app unit tests interacting with windows \
can run<br>&nbsp; &nbsp;on Windows.<br>&nbsp; &nbsp;More details: The following fails on our \
windows CI<br>&nbsp; &nbsp;<a \
href="https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp" rel="noreferrer" \
target="_blank">https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp</a><br>&nbsp; \
&nbsp;I find it weird that we are spending resources on putting things in<br>&nbsp; &nbsp;the \
windows store and making apps available on windows, but we can't<br>&nbsp; &nbsp;actually have \
passing tests in our CI.<br></div><br></blockquote><div><br></div><div>This unfortunately will \
not be easy to solve.&nbsp;</div><div><br></div><div>One of the key things that we've learned \
out of doing CI, as has been showcased&nbsp;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.</div><div>We're currently accomplishing this by using containers - via Podman (for \
Linux/Android/FreeBSD) and Docker (for Windows).<br></div><div><br></div><div>Containers also \
offer us the advantage of allowing people to easily reproduce the CI environment on their local \
system without too much trouble.</div><div><br></div><div>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.</div><div><div><br></div><div>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.</div><div><div>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).</div></div></div></div></div></blockquote><div><br></div><div>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?</div><div><span></span></div></body></html>



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic