qemu-s390x
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH-for-5.2 2/3] gitlab-ci: Add a job to cover the --without-defa


From: Thomas Huth
Subject: Re: [PATCH-for-5.2 2/3] gitlab-ci: Add a job to cover the --without-default-devices config
Date: Wed, 4 Nov 2020 10:15:31 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0

On 04/11/2020 09.32, Philippe Mathieu-Daudé wrote:
> On 11/4/20 7:21 AM, Thomas Huth wrote:
>> On 03/11/2020 21.41, Philippe Mathieu-Daudé wrote:
>>> On 11/3/20 7:43 PM, Thomas Huth wrote:
>>>> On 03/11/2020 17.46, Philippe Mathieu-Daudé wrote:
>> [...]
>>>>> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
>>>>> index 3b15ae5c302..6ee098ec53c 100644
>>>>> --- a/.gitlab-ci.yml
>>>>> +++ b/.gitlab-ci.yml
>>>>> @@ -262,6 +262,17 @@ build-user-plugins:
>>>>>      MAKE_CHECK_ARGS: check-tcg
>>>>>    timeout: 1h 30m
>>>>>  
>>>>> +build-system-ubuntu-without-default-devices:
>>>>> +  <<: *native_build_job_definition
>>>>> +  variables:
>>>>> +    IMAGE: ubuntu2004
>>>>> +    CONFIGURE_ARGS: --without-default-devices --disable-user 
>>>>> --disable-xen --disable-tools --disable-docs
>>>>> +    MAKE_CHECK_ARGS: check-build
>>>>
>>>> AFAIK "check-build" is pretty much a no-op since the convertion to meson 
>>>> ...
>>>> could you maybe replace with a set of qtest targets that work, to make sure
>>>> that we do not regress here? E.g.:
>>>>
>>>> MAKE_CHECK_ARGS: check-qtest-avr check-qtestcris check-qtest-m68k
>>>> check-qtest-microblaze check-qtest-mipsel check-qtest-moxie ...
>>>
>>> qtests don't work with --without-default-devices, as we don't check
>>> for (un-)available devices.
>>
>> Sure, "make check-qtest" does not work, I know. But some targets work fine,
>> e.g. "make check-qtest-avr", and that's what I've suggested.
> 
> Yes, I tested that successfully yesterday late.
> 
>> By testing
>> those targets, we can make sure that the qtests don't regress any further
>> with --without-default-devices.
> 
> Yes, but I'm being wary to use it with the sole AVR target, because
> I don't want this target development to be limited by unrelated
> technical debts (in case we add optional device on an AVR board).

If you feel uncomfortable with check-qtest-avr, you could also use
check-qtest-m68k instead - I think that's fine for me (and hopefully also
Laurent).

 Thomas




reply via email to

[Prev in Thread] Current Thread [Next in Thread]