DRM CI

[Helen Koike]

Hi Maxime,

Thanks for your reply.

On 20/03/2025 06:33, 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.
> 
> 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.
> 

This is the effort kci-gitlab is doing (see last patch with a drm-ci 
proposal), to simplify things and remove the dependency of mesa-ci.

>      I guess we could try to improve and consolidate it, but for a script
>      that simple, I don't think it's worth it.

Well, we are splitting our community in some way...

> 
>      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.

No need to a super generic implementation. At least in kci-gitlab, there 
is room to very specific implementations.

> 
>      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.

(I confess I'm not following that thread, I'm guilty on that)

If we are going this way, maybe it is better to remove DRM-CI completely 
from the kernel code?

Just to be clear, I'm not opposing anything, I just want to understand 
how everything would fit together.

Regards,
Helen

> 
> Maxime