DRM CI

[Vignesh Raman]

Hi Maxime,

On 20/03/25 15:03, Maxime Ripard wrote:
> Hi,
> 
> On Wed, Mar 19, 2025 at 02:39:59PM -0300, Helen Koike wrote:
>> Hi Maxime,
>>
>> On 19/03/2025 11:11, Maxime Ripard wrote:
>>> Hi,
>>>
>>> At last Plumbers, we agreed with Dave that a good first step to ramp up
>>> CI for DRM trees would be to enable build and kunit testing in the main
>>> DRM tree.
>>>
>>> I played around with it last week and wrote a good first iteration of
>>> the gitlab-ci file.
>>>
>>> https://gitlab.freedesktop.org/mripard/gitlab/-/blob/main/.gitlab-ci.yml?ref_type=heads
>>
>> How about improving and using the current DRM-CI instead of creating a
>> new one?
> 
> Thanks for the suggestion, and I did try. I don't think it's a good
> option though, at first at least.

Thanks for the patch.

Will we have this gitlab-ci.yml for kunit/compilation and for igt tests
on hardware the existing drm-ci?

I tried adding kunit tests (only for x86_64) in existing drm-ci. Please 
see the below commit and pipeline.

https://gitlab.freedesktop.org/vigneshraman/linux/-/commit/dda0c011c26611132238f0769482a95ceae0f515

https://gitlab.freedesktop.org/vigneshraman/linux/-/jobs/73091231

Please let me know your opinion on this. Thanks.

> 
> There's several layers to it:
> 
>    - The most important one is I don't really see much to share at this
>      point, really. The containers creation is a good example of
>      something useful, reusable, and that I did use. However, drm-ci uses
>      different defconfigs, its own set of hardcoded compilers, etc.

It uses different configs only when building the kernel for hardware 
testing. For the build job, it uses the default defconfigs.

> 
>      I guess we could try to improve and consolidate it, but for a script
>      that simple, I don't think it's worth it.
> 
>      Similarly, I don't think it makes sense to try to come up with a
>      super generic implementation of kunit, when there's only one user.
> 
>      That, of course, can and should be reevaluated as we test more
>      features and the script does indeed become more complicated.
> 
>    - We discussed it during the thread with Linus, but I also don't think
>      a one-size-fits-all approach is going to work. drm-ci at the moment
>      has plenty of reasonable policies, but which people are still going
>      to have different opinions on. Like, whether you want to
>      aggressively update IGT or mesa. Or whether or not you are willing
>      to disable KASAN to accomodate db410c and db820c. The choices made
>      in drm-ci so far are reasonable, but choosing something else is just
>      as reasonable. That's why I thought at the time that providing
>      common scripts to include is a better way forward than a gitlab-ci
>      file everybody is supposed to use.
> 
>    - To some extent, the complaints Rob had last week about drm-ci
>      expectations not being updated fast enough in drm-misc are related
>      as well. It could also easily be solved by drm/msm having the
>      gitlab-ci script and its expectations in a separate repo, under the
>      msm maintainers control. And then it could go as fast as they want,
>      under their terms, without creating any impedance mismatch with the
>      rest of DRM.

Will the msm maintainers update the expectations in a separate repo and 
then merge them back to drm subsystem ci folder ?

Regards,
Vignesh

> 
> Maxime