RE: [PATCH v2 0/5] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing

Bird, Tim
2025-01-24T20:00:38Z

> -----Original Message-----
> From: Helen Mae Koike Fornazier <helen.koike@collabora.com>
> Hi Mauro,
>
> ---- On Fri, 24 Jan 2025 12:29:16 -0300 Mauro Carvalho Chehab wrote ---
>
> > Em Fri, 24 Jan 2025 09:26:33 -0500
> > Nicolas Dufresne nicolas.dufresne@collabora.com> escreveu:
> >
> > > Hi,
> > >
> > > Le vendredi 24 janvier 2025 à 15:00 +0200, Nikolai Kondrashov a écrit :
> > > > On 1/24/25 2:16 PM, Jarkko Sakkinen wrote:
> > > > > On Fri Jan 24, 2025 at 10:12 AM EET, Laurent Pinchart wrote:
> > > > > > Gitlab as an open-source software project (the community edition) is one
> > > > > > thing, but can we please avoid advertising specific proprietary services
> > > > > > in the kernel documentation ?
> > > > >
> > > > > I don't think we should have any of this in the mainline kernel.
> > > > >
> > > > > One angle is that "no regressions rule" applies also to the shenanigans.
> > > > >
> > > > > Do we really spend energy on this proprietary crap to the eternity?
> > > >
> > > > This is not getting included into the kernel itself, the contributed code is,
> > > > of course, open-source. And yes it would execute just fine on the fully
> > > > open-source community-edition GitLab.
> >
> > > > I don't think "no regressions rule" should apply here.
> >
> > It doesn't, as this is not a Kernel userspace API. It is just some
> > facility to integrate Kernel builds using a CI infrastructure. This can
> > change with time as needed.
> >
> > Still, once people start using it, developers need to take some care to
> > avoid regressions that would cause CI builds to fail for the ones using
> > such facilities.
> >
> > Also, ideally, this should be completely independent of the Kernel version,
> > e.g. if one sets up an infra using the version that was there when, let's
> > say, Kernel 6.14 is released, the same CI scripts should work just fine
> > with stable Kernels and even future Kernels.
>
> Or you can just configure your GitLab CI to work and an older version of
> the script by just pointing the right yaml URL at that versions in the configs,
> or am I missing something?
>
> >
> > Due to that, I'm not convinced that such kernel CI files should be
> > hosted at the Kernel tree.
> >
> > IMO, this should be stored on a separate repository hosted at
> > kernel.org, using Semantic Versoning (https://semver.org/) - e. g.
> > when there are incompatible changes, major version number will be
> > increased.
>
> A key benefit of having it in-tree is the test expectation list, as seen with
> DRM-CI. This allows developers to track the state of drivers and progress over
> time by showing which tests are expected to pass or fail at a given point in
> history. (From what I see in DRM-CI, this adds a considerable amount of value.)
> Please check the VKMS patch in this patchset.
>
> Also, if we keep this tool out of tree, I’m concerned that subsystems like DRM
> and Media will continue not collaborating—each currently has its own solution
> when the base could be shared and reused. All static checks, build processes,
> and boot mechanisms are fundamentally the same, with only minor differences
> that are customizable. Other subsystems could use just the base or build their
> specific configurations/tests on top of it.
> Having it in-tree sends a message: "You can create your own GitLab CI pipeline,
> but why not use this existing one, contribute to it, and collaborate for
> everyone's benefit?".
> Since it's under the tools/ folder, it’s a helper tool.

Although I don't use gitlab CI for my kernel testing (I use Fuego), I've been
waiting for this so that I can see if it's possible to leverage the information
contained in it for my own CI system. I may not end up using the info myself,
but at a minimum it will show me the info needed by another CI system.

Having this upstream is useful, IMHO, even if it just reflects a single CI system
currently being used.
-- Tim

> > > > This is for developers only, and is a template for making
> > > > your own pipeline mostly, with pieces which can be reused.
> > >
> > > Perhpas worth clarifying that Media and DRM subsystem have opted for the
> > > Freedesktop instance. This instance is running the Open Source version of
> > > Gitlab, with hundreds of CI runners contributed and shared among many projects
> > > (which includes Mesa, GStreamer, Wayland, Pipewire, libcamera, just to name
> > > few).
> >
> > It doesn't matter much what git forge some projects are currently using, as
> > things like that could change with time.
> >
> > Starting with supporting just one type of git forge sounds OK to me,
> > but long term goal should be to make it generic enough to be used with as
> > much CI engines as possible - not only forges developed by companies that
> > provide paid services like Gitlab/Github, but also completely open
> > source forges and even Jenkins.
> >
> > Thanks,
> > Mauro
> >
>