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

[Thomas Huth]

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