Hi Maxime,
On 20/03/25 15:03, 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.
Thanks for the patch.
Will we have this gitlab-ci.yml for kunit/compilation and for igt tests
on hardware the existing drm-ci?
I tried adding kunit tests (only for x86_64) in existing drm-ci. Please
see the below commit and pipeline.
https://gitlab.freedesktop.org/vigneshraman/linux/-/commit/dda0c011c26611132238f0769482a95ceae0f515
https://gitlab.freedesktop.org/vigneshraman/linux/-/jobs/73091231
Please let me know your opinion on this. Thanks.
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.
It uses different configs only when building the kernel for hardware
testing. For the build job, it uses the default defconfigs.
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.
Will the msm maintainers update the expectations in a separate repo and
then merge them back to drm subsystem ci folder ?
Regards,
Vignesh
Maxime
