Re: [PATCH] .gitlab-ci.d/windows.yml: Disable the qtests in the MSYS2 job

[Thomas Huth]

On 19/08/2024 12.21, Philippe Mathieu-Daudé wrote:
> On 19/8/24 07:30, Thomas Huth wrote:
> > On 16/08/2024 19.18, Philippe Mathieu-Daudé wrote:
> > > On 16/8/24 18:40, Thomas Huth wrote:
> > > > On 16/08/2024 18.34, Philippe Mathieu-Daudé wrote:
> > > > > On 16/8/24 17:37, Thomas Huth wrote:
> > > > > > The qtests are broken since a while in the MSYS2 job in the gitlab-CI,
> > > > > > likely due to some changes in the MSYS2 environment. So far nobody has
> > > > > > neither a clue what's going wrong here, nor an idea how to fix this
> > > > > > (in fact most QEMU developers even don't have a Windows environment
> > > > > > available for properly analyzing this problem), so let's disable the
> > > > > > qtests here again to get at least the test coverage for the compilation
> > > > > > and unit tests back to the CI.
> > > > > >
> > > > > > Signed-off-by: Thomas Huth <thuth@redhat.com>
> > > > > > ---
> > > > > >   .gitlab-ci.d/windows.yml | 2 ++
> > > > > >   1 file changed, 2 insertions(+)
> > > > > >
> > > > > > diff --git a/.gitlab-ci.d/windows.yml b/.gitlab-ci.d/windows.yml
> > > > > > index a83f23a786..9f3112f010 100644
> > > > > > --- a/.gitlab-ci.d/windows.yml
> > > > > > +++ b/.gitlab-ci.d/windows.yml
> > > > > > @@ -23,6 +23,8 @@ msys2-64bit:
> > > > > >       # for this job, because otherwise the build could not complete 
> > > > > > within
> > > > > >       # the project timeout.
> > > > > >       CONFIGURE_ARGS:  --target-list=sparc-softmmu 
> > > > > > --without-default-devices -Ddebug=false -Doptimization=0
> > > > > > +    # The qtests are broken in the msys2 job on gitlab, so disable them:
> > > > > > +    TEST_ARGS: --no-suite qtest
> > > > >
> > > > > Then building system emulation is pointless, isn't it?
> > > >
> > > > We're still running the unit tests and some others.
> > >
> > > I tried to configure with '--disable-system' and the same tests
> > > are run
> >
> > ... but you lose *compile-testing* of all of the system files, so what's 
> > your point? ... sorry, I don't get it?
>
> I'm wondering why wasting resources and time on our longest job
> if the produced binary doesn't run. Anyway, I'm not objecting to
> your patch.

Ah, ok, I missed that idea about one of the longest running jobs. Hmmm, 
considering that we compile test the code in the cross-win64-system test, 
too, we could indeed shorten the runtime here a little bit ... I'll give it 
a try and send a v2...

 Thomas