|
From: | Thomas Huth |
Subject: | Re: [PATCH] gitlab-ci: Add jobs to build standalone machines |
Date: | Thu, 17 Jun 2021 13:45:23 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |