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

[Thomas Huth <thuth@redhat.com>]

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