<div dir="ltr"><div dir="ltr">On Thu, Feb 25, 2021 at 11:11 AM David Faure <<a href="mailto:faure@kde.org" target="_blank">faure@kde.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On mercredi 24 février 2021 09:51:28 CET Ben Cooksley wrote:<br>
> On Wed, Feb 24, 2021 at 3:03 AM David Faure <<a href="mailto:faure@kde.org" target="_blank">faure@kde.org</a>> wrote:<br>
> > On mardi 23 février 2021 10:42:44 CET Ben Cooksley wrote:<br>
> > > This sounds like it could be caused by the lack of access to the<br>
> > > > graphical<br>
> > <br>
> > > session - which is what I was hoping to ensure would still happen if we<br>
> > <br>
> > ran<br>
> > <br>
> > > it as a scheduled task vs. as a Windows service (as these don't get any<br>
> > > graphical rights at all, as they're not supposed to do anything like<br>
> > > that<br>
> > > anymore)<br>
> > > <br>
> > > Did this failure show up sometime recently, or has it always been<br>
> > <br>
> > failing?<br>
> > <br>
> > I can't remember this test ever passing on Windows, actually.<br>
> > I'd say it's always been failing.<br>
> <br>
> Damn. Do we have any other tests that try to do similar things with windows<br>
> that are also affected?<br>
> (Just to be sure that is the issue here)<br>
<br>
Good point.<br>
Here's my investigation of all the tests that use qWaitForWindowExposed:<br>
<br>
kwidgetsaddons/autotests/kpasswordlineedittest.cpp  FAIL<br>
kwidgetsaddons/autotests/ksplittercollapserbuttontest.cpp   FAIL<br>
kwidgetsaddons/autotests/kcolorbuttontest.cpp  FAIL<br>
kwidgetsaddons/autotests/ktooltipwidgettest.cpp  FAIL<br>
ktexteditor/autotests/src/kateview_test.cpp  FAIL! 'QTest::qWaitForWindowExposed(view)' returned FALSE. ()<br>
ktexteditor/autotests/src/messagetest.cpp  FAIL! 'QTest::qWaitForWindowExposed(view)' returned FALSE. ()<br>
kio/autotests/kfilecustomdialogtest.cpp => tests seem to be disabled completely on Windows :(<br>
plasma-framework/autotests/iconitemtest.cpp FAIL!  'QTest::qWaitForWindowExposed(m_view)' returned FALSE. ()<br>
plasma-framework/autotests/dialognativetest.cpp => X11 only test, not run<br>
<br>
So, yes, qWaitForWindowExposed fails in our Windows CI, always.<br></blockquote><div><br></div><div>Doing some searching confirmed my fears here, that even though we're running under the Task Scheduler, in most cases we won't have interactive desktop access - which is needed here to show windows. <a href="https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc722152(v=ws.11)?redirectedfrom=MSDN" target="_blank">https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc722152(v=ws.11)?redirectedfrom=MSDN</a> and <a href="https://serverfault.com/questions/101671/scheduled-tasks-w-gui-issue">https://serverfault.com/questions/101671/scheduled-tasks-w-gui-issue</a> detail this sadly.</div><div><br></div><div>It should be noted that running as a service is also off the table, per <a href="https://docs.microsoft.com/en-us/windows/win32/services/interactive-services" target="_blank">https://docs.microsoft.com/en-us/windows/win32/services/interactive-services</a></div><div><br></div><div>I'll have a think about our options here - we're a little limited alas as we also need the runner process for the Binary Factory to start as well. I suspect our only option will be to have Windows automatically login as the CI user, and for us to manually start the Binary Factory worker after the system has started up.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
-- <br>
David Faure, <a href="mailto:faure@kde.org" target="_blank">faure@kde.org</a>, <a href="http://www.davidfaure.fr" rel="noreferrer" target="_blank">http://www.davidfaure.fr</a><br>
Working on KDE Frameworks 5<br>
<br>
<br>
<br></blockquote><div><br></div><div>Cheers,</div><div>Ben </div></div></div>