Re: [PATCH] gitlab-ci: Add jobs to build standalone machines

[Thomas Huth <thuth@redhat.com>]

On 17/06/2021 12.42, Alex Bennée wrote:
> 
> Philippe Mathieu-Daudé <f4bug@amsat.org> writes:
> 
>> The --without-default-devices configure option removes the
>> 'default=y' from Kconfig files. It is useful to test missing
>> Kconfig dependencies for users wanting to have QEMU (system)
>> binaries with a particular subset of machines builtin.
>>
>> If a machine can be built standalone, it can certainly be
>> built as part of a set. So the best way to test for regressions
>> is to test each machine individually.
>>
>> As this is painful to test manually, add CI jobs to do it [*].
>> Since all jobs follow the same template, to ease maintenance
>> we generate the jobs using the jsonnet tool, which emit a YAML
>> file filled with all our jobs.
>>
>> Since there is no "--enable-my-config" option, we have to write
>> the standalone config manually, overwritting each target .mak
>> file in default-configs/devices/.

I'd appreciate if we could get such a --enable-config option first - that 
would also be very helpful for downstream RHEL where we also modify the 
default-configs with downstream-only patches.

>> +
>> +{
>> +  include: { "local": "/.gitlab-ci.d/standalone-jobs-template.yml" },
>> +
>> +    "alpha dp264": param_job("alpha-softmmu", "CONFIG_DP264=y"),
>> +    "avr arduino": param_job("avr-softmmu", "CONFIG_ARDUINO=y"),
>> +    "hppa dino": param_job("hppa-softmmu", "CONFIG_DINO=y"),
>> +    "nios2 10m50": param_job("nios2-softmmu", "CONFIG_NIOS2_10M50=y"),
>> +    "nios2 nommu": param_job("nios2-softmmu", "CONFIG_NIOS2_GENERIC_NOMMU=y"),
>> +    "or1k sim": param_job("or1k-softmmu", "CONFIG_OR1K_SIM=y"),
>> +    "rx gdbsim": param_job("rx-softmmu", "CONFIG_RX_GDBSIM=y", "-bios /dev/null"),
>> +    "triboard": param_job("tricore-softmmu", "CONFIG_TRIBOARD=y"),
>> +    "xtensa sim": param_job("xtensaeb-softmmu", "CONFIG_XTENSA_SIM=y CONFIG_SEMIHOSTING=y"),
>> +    "xtensa virt": param_job("xtensa-softmmu", "CONFIG_XTENSA_VIRT=y CONFIG_SEMIHOSTING=y"),
> 
> Do we really have a plethora of users running trimmed down custom
> configurations that we need to defend each of these exotic build
> combinations in the CI?

I think I agree with Alex - in our CI, we should test what users really 
need, and not each and every distantly possible combination.

So what I'd really would like to see:

1) Introduce a "--with-build-configs" switch (feel free to bikeshed on the 
name) to the configure script that allows us to use a folder with a 
different set of config files.

2) rename default-configs/ to configs/default/

3) Introduce some useful alternate config sets, e.g. configs/rhel or 
configs/lean-kvm or whatever people want to use, and change some of the CI 
jobs to work with those configs.

  Thomas