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

Mark Brown <[email protected]> Fri, 24 Jan 2025 17:15:03 +0000

Newsgroups	dev.linux.lists.kernelci,fr.inria.cocci,org.freedesktop.lists.dri-devel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.kernel.vger.workflows
Message-ID	<[email protected]>

On Fri, Jan 24, 2025 at 06:32:07PM +0200, Jarkko Sakkinen wrote:

> Can we then agree that any CI changes can be sent untested to LKML if
> a patch set needs to reflect on those? It's not reasonable to except
> local runs Gitlab from individuals for patch sets. It makes our lives
> more difficult, not easier.

I think the theory here is that this more shared building blocks for
people who want to set something up using gitlab rather than the one
true CI system that everyone has to use.  Even with people who do end up
using gitlab there's going to be issues with things like hardware access
and just realistic resources which mean that not everyone can test
everything.  We generally have an expectation that people will make a
reasonable effort to test things, not that they're going to cover
everything, and I don't see why this should be different.

> All maintainers I know test their patches for the most part with
> BuildRoot, distro VM's and stuff like that. Not claiming that they
> don't exist, but never heard of kernel maintainer who uses Gitlab
> as their main kernel testing tool.

There's a huge diversity in what people are using for their CI
infrastructure, gitlab instances are definitely in there already.  The
last time I looked at the implementation the clang testing was driven
through gitlab, AIUI the DRM and media systems also have something.  One
of the ways gitlab is handy is that it's something that companies are
likely to have set up anyway which helps with getting things
provisioned.

> > Sure, a script could be contributed too, but the value of this contribution is
> > a ready-made integration. And we want to make it easily discoverable, and
> > easily contributed to.

> This is definitely NOT "lots of flexibility".

> Are you dead seriously claiming that DevOps engineers could not handle
> well defined CI scripts and bind to whatever CI makes sense to them?
> o_O

There's going to be an audience out there for people who aren't
specifically devops people and would find it helpful to have something
to look at when getting started, and even where people are capable of
doing the work it seems helpful to pool effort on the more common stuff.

signature.asc (application/pgp-signature, 488 B)