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
