Re: [PATCH 1/3] automation: Drop ppc64le-*randconfig jobs

[Jan Beulich <jbeulich@xxxxxxxx>]

On 26.09.2023 21:49, Andrew Cooper wrote:
> On 25/09/2023 11:42 pm, Shawn Anastasio wrote:
>> Since ppc64le is still undergoing early bringup, disable the randconfig
>> CI build which was causing spurious CI failures.
>>
>> Signed-off-by: Shawn Anastasio <sanastasio@xxxxxxxxxxxxxxxxxxxxx>
>> Reported-by: Jan Beulich <jbeulich@xxxxxxxx>
>> ---
>>  automation/gitlab-ci/build.yaml | 18 ------------------
>>  1 file changed, 18 deletions(-)
>>
>> diff --git a/automation/gitlab-ci/build.yaml 
>> b/automation/gitlab-ci/build.yaml
>> index 1619e9a558..32af30cced 100644
>> --- a/automation/gitlab-ci/build.yaml
>> +++ b/automation/gitlab-ci/build.yaml
>> @@ -563,24 +563,6 @@ debian-bullseye-gcc-ppc64le-debug:
>>      KBUILD_DEFCONFIG: ppc64_defconfig
>>      HYPERVISOR_ONLY: y
>>  
>> -debian-bullseye-gcc-ppc64le-randconfig:
>> -  extends: .gcc-ppc64le-cross-build
>> -  variables:
>> -    CONTAINER: debian:bullseye-ppc64le
>> -    KBUILD_DEFCONFIG: ppc64_defconfig
>> -    RANDCONFIG: y
>> -    EXTRA_FIXED_RANDCONFIG:
>> -      CONFIG_COVERAGE=n
>> -
>> -debian-bullseye-gcc-ppc64le-debug-randconfig:
>> -  extends: .gcc-ppc64le-cross-build-debug
>> -  variables:
>> -    CONTAINER: debian:bullseye-ppc64le
>> -    KBUILD_DEFCONFIG: ppc64_defconfig
>> -    RANDCONFIG: y
>> -    EXTRA_FIXED_RANDCONFIG:
>> -      CONFIG_COVERAGE=n
> 
> I know this has been committed, but it shouldn't have been.  Randconfig
> is important to have even at this point in the bringup.

Well. As so often you only comment when it's too late. The question whether
randconfig is sensible to have in the bringup phase was raised earlier. You
could have said "yes, keep it" there. With there not having been any comment
on the suggestion to drop this (and I similarly think for RISC-V, which is
likely to be similarly affected the moment the full build is enabled there),
I didn't expect any opposition to the patch, and hence went ahead committing
it.

> For options which are known-incompatible, append them to
> EXTRA_FIXED_RANDCONFIG, just like COVERAGE already is.

But in this early phase that merely means re-stating some/all of what the
default config states (which may in fact state a few too many fixed
settings).

> However, it was only grant tables which showed up as broken, and ought
> to be easy to address.

It may only be grant tables right now (that's what CI had spotted), but
other settings are likely to become (transient) problems as well. See
e.g.

#define smp_processor_id() 0 /* TODO: Fix this */

which imo might lead to the compiler spot bogus constructs, just because
at the same time NR_CPUS > 1.

Jan