Re: [for-4.17] automation: Build Xen according to the type of the job

[Michal Orzel <michal.orzel@xxxxxxx>]

On 21/10/2022 16:32, Michal Orzel wrote:
> 
> 
> Hi Andrew,
> 
> On 21/10/2022 15:31, Andrew Cooper wrote:
>>
>>
>> On 21/10/2022 14:22, Michal Orzel wrote:
>>> All the build jobs exist in two flavors: debug and non-debug, where the
>>> former sets 'debug' variable to 'y' and the latter to 'n'. This variable
>>> is only being recognized by the toolstack, because Xen requires
>>> enabling/disabling debug build via e.g. menuconfig/config file.
>>> As a corollary, we end up building/testing Xen with CONFIG_DEBUG always
>>> set to a default value ('y' for unstable and 'n' for stable branches),
>>> regardless of the type of the build job.
>>>
>>> Fix this behavior by setting CONFIG_DEBUG according to the 'debug' value.
>>>
>>> Signed-off-by: Michal Orzel <michal.orzel@xxxxxxx>
>>> ---
>>> Xen used debug variable to control the build type before switching to 
>>> Kconfig.
>>> Support for GitLab CI was added later, which means that this issue was 
>>> always
>>> present. This is a low risk for 4.17 with a benefit of being able to test 
>>> Xen
>>> in both debug and non-debug versions.
>>
>> Both series were floating around for ages before being accepted.  It's
>> quite possible that one bitrotted around the other.
>>
>> This should be backported, and therefore should be considered for 4.17
>> at this point.
>>
>> Is there a Gitlab CI run which includes this patch?
> 
> I submitted the one here not long ago:
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.com%2Fxen-project%2Fpeople%2Fmorzel%2Fxen-orzelmichal%2F-%2Fpipelines%2F673396949&amp;data=05%7C01%7Cmichal.orzel%40amd.com%7Cd091891dbc3a4144356d08dab37120ae%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638019595719666762%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=r6qIERShnnovl57xvY%2Fo8eKozAy9NBlqyj0le56ZClY%3D&amp;reserved=0
> 
> and there is already one failure in Arm boot-cpupools test because the script 
> sets null
> scheduler for the domain which is not present in non-debug build...

The CI finished running the pipeline and it looks like the null sched issue is 
the only one (at least this means that this patch is worth having).
I will push a fix for the boot-cpupools test (I will also mark it as for-4.17).

> 
>>
>> ~Andrew
> 
> ~Michal
> 

~Michal