Re: [PATCH 1/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing

Mark Brown <[email protected]>
Newsgroups dev.linux.lists.kernelci,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, Mar 01, 2024 at 12:27:13PM +0200, Nikolai Kondrashov wrote:
> On 2/29/24 10:21 PM, Linus Torvalds wrote:

> > We already have the situation that the drm people have their own ci
> > model. II'm ok with that, partly because then at least the maintainers
> > of that subsystem can agree on the rules for that one subsystem.

> > I'm not at all interested in having something that people will then
> > either fight about, or - more likely - ignore, at the top level
> > because there isn't some global agreement about what the rules are.

> > For example, even just running checkpatch is often a stylistic thing,
> > and not everybody agrees about all the checkpatch warnings.

...

> > I would suggest the CI project be separate from the kernel.

> It is possible to have a GitLab CI setup with the YAML files in a separate
> repository. And we can start with that. However, ultimately I think it's
> better to have it in the same repo with the code being tested. This way you
> could submit code changes together with the required tweaks to the CI to keep
> it passing, making development smoother and faster.

> With that in mind, and if you agree, where else would you say we could put it?
> Under "scripts"? Or "Documentation"? And where it would be best for the
> various subsystems to put theirs? Or could we have the top-level "ci" dir and
> pile all the different setups there? Or would you like to wait and see how
> adoption goes, and then decide?

If we were going to put bits of this in tree how about something like
tools/testing/forges?  I'd hope that things could be shared by multiple
services, if not we could always have subdirs I guess.  We could put
glue bits like defining how to run kunit, checkpatch or whatever with
these systems in there so people can share figuring that bit out.
Individual trees or CI systems using these forge based systems could
then reference these files when defining what specific tests they want
to run when which seems more like where the differences will be.

I'm not super familiar with this stuff, the above is based on it looking
like there's an OK degree of separation between the "what to run" and
"how to run" bits.  I might be misreading things, and it's not clear to
me how often it'll be useful to be able to update things in tree.
signature.asc (application/pgp-signature, 488 B)
-----BEGIN PGP SIGNATURE-----

iQEzBAABCgAdFiEEreZoqmdXGLWf4p/qJNaLcl1Uh9AFAmXh4SoACgkQJNaLcl1U
h9Bblwf/VTM6YUfyvCiFxlO2Sxm0DvgYcdMKFDVe0Iwu6FKdwHafjgfDIAW/fydL
Zseb1Kh+uo2pgtj0H6hU5ZNPVzux4lyYsfO7aWhZePjev836VEqMIEeJJp7Xxc+G
GyrpLnxWa/q+WvHh/dOycgP8JdJTWIoPPP27rSFGsgikoqTVhtJUF2ld6MPJGSbe
2Gna3Kd/ALF9sms7c/ND6qWhoqLlsjFF7v6SDUuOHfVozPdez72lpAx0WLSdj29D
9Bm2oGIEPWS1dlyXRXh34AaUeUFqXnr0kK2fgOkadM/ndszTaB3+X3ujZXC2MCUL
+5OwpbUNLXA9RkS8JN2anvXIQ9uuGg==
=mh+h
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.