DRM CI

[Helen Koike]

On 28/03/2025 13:11, Maxime Ripard wrote:
> On Thu, Mar 20, 2025 at 09:32:36AM -0300, Helen Koike wrote:
>> 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.
> 
> Do you have a link to that patch?

Yes, please check 
https://lore.kernel.org/all/20250123135342.1468787-1-vignesh.raman@collabora.com/

There is a link to v1 as well, where kunit is mentioned.

> 
>>>       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...
> 
> I don't think so? In KMS, we tend to provide a default behaviour with
> helpers, but any driver is free to deviate from that if it makes sense.
> One of these reasons is that there's no point in trying to make
> something specific to a driver generic until there is multiple users for
> it. So we have plenty of drivers that don't use the helpers and the
> "default" solution.
> 
> A community isn't a single codebase, it's a single set of people working
> on the same set of problems. If anything, allowing deviation is better
> for a community, because then we can have the discussion we have right
> now, and we don't work in silos.
> 
> Now, if we start saying "ok, any CI in DRM must be done on Debian, with
> bleeding edge mesa and igt", then we're splitting the community, because
> it just won't work for some people, and they'll still have to make it
> work.
> 
>>>       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.
> 
> I think it really has value as a "library" or repo, kind of how github
> actions work for example. Providing something that would, say, configure
> and build the kernel and report the status as a comment on a PR would be
> awesome. And there's no reason not to share that. But I believe every
> maintainer will need to glue the whole thing together how they see fit.
> 

Sure, I just don't want us to re-do things all the time, if we manage to 
find a way to share I'm fine with that.


Regards,
Helen