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. 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. Maxime
Attachment:
signature.asc
Description: PGP signature
