DRM CI

[Maxime Ripard]

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?

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

Maxime
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20250328/03f8fd5e/attachment.sig>