Re: [PATCH] automation: Add container and build jobs to run cppcheck analysis

[Andrew Cooper <andrew.cooper3@xxxxxxxxxx>]

On 14/02/2023 11:45 am, Michal Orzel wrote:
> Hi Andrew,
>
> On 14/02/2023 12:00, Andrew Cooper wrote:
>>
>> On 13/02/2023 2:23 pm, Michal Orzel wrote:
>>> Add a debian container with cppcheck installation routine inside,
>>> capable of performing cppcheck analysis on Xen-only build including
>>> cross-builds for arm32 and arm64.
>>>
>>> Populate build jobs making use of that container to run cppcheck
>>> analysis to produce a text report (xen-cppcheck.txt) containing the list
>>> of all the findings.
>>>
>>> This patch does not aim at performing any sort of bisection. Cppcheck is
>>> imperfect and for now, our goal is to at least be aware of its reports,
>>> so that we can compare them with the ones produced by better tools and
>>> to be able to see how these reports change as a result of further
>>> infrastructure improvements (e.g. exception list, rules exclusion).
>>>
>>> Signed-off-by: Michal Orzel <michal.orzel@xxxxxxx>
>>> ---
>>> For those interested in, here is a sample pipeline:
>>> https://gitlab.com/xen-project/people/morzel/xen-orzelmichal/-/pipelines/775769167
>>> ---
>>>  .../build/debian/unstable-cppcheck.dockerfile | 37 +++++++++++++++++
>>>  automation/gitlab-ci/build.yaml               | 40 +++++++++++++++++++
>>>  automation/scripts/build                      | 11 ++++-
>> I'm afraid that I'm going to start pushing back on any more x86 jobs.
>>
>> We're already at several hours to get a run out of Gitlab CI, and that's
>> assuming none of them hit networking issues, and outside of the typical
>> European working day, when patchew is busy churning and not reporting
>> the status back.
>>
>> Right now, there is vastly more ARM test resource than x86 resource, as
>> evidence by the fact that you're never waiting more than a few minutes
>> for the actually-ARM tests to complete, so adding more x86 cross
>> compiles is compounding the problem.
>>
>> We need less x86 testing, or more x86 resource.  Probably both, because
>> its now so long that even I'm not using it as a pre-push gate on all
>> changes.
> I'm aware of the problem you described. AFAICT there is nothing stopping us
> from switching completely the arm32 cross builds from x86 to arm64 container.
> It is just a matter of creating identical container to unstable-arm32-gcc
> e.g. unstable-arm64v8-arm32-gcc and using FROM arm64v8/debian:unstable.
> We need to keep the old container for backwards compatibility.
>
> This way, x86 runners will only do x86 stuff + riscv64.
>
> Are you aware of anything preventing us to do so?
> If not, I will push a prereq patch to switch the arm32 cross build to arm64.

No issues that I can see - I think that would be a good move in the
short term.  And it's also something that should be backported to
alleviate pressure there.

On the x86 side, we also desperately need to prune some legacy things. 
Guess I'll get around to that is some copious free never.

~Andrew