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

[Bird, Tim]

> -----Original Message-----
> From: Helen Mae Koike Fornazier <helen.koike at 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 at 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
>  >
>