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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <44ae0339-daf1-4bb9-a12d-e3d2e79b889e@gmail.com>
Date: Fri, 1 Mar 2024 12:27:13 +0200
From: Nikolai Kondrashov <spbnick@...il.com>
To: Linus Torvalds <torvalds@...uxfoundation.org>
Cc: Maxime Ripard <mripard@...nel.org>,
 Helen Koike <helen.koike@...labora.com>, linuxtv-ci@...uxtv.org,
 dave.pigott@...labora.com, linux-kernel@...r.kernel.org,
 dri-devel@...ts.freedesktop.org, linux-kselftest@...r.kernel.org,
 gustavo.padovan@...labora.com, pawiecz@...labora.com,
 tales.aparecida@...il.com, workflows@...r.kernel.org,
 kernelci@...ts.linux.dev, skhan@...uxfoundation.org,
 kunit-dev@...glegroups.com, nfraprado@...labora.com, davidgow@...gle.com,
 cocci@...ia.fr, Julia.Lawall@...ia.fr, laura.nao@...labora.com,
 ricardo.canuelo@...labora.com, kernel@...labora.com,
 gregkh@...uxfoundation.org
Subject: Re: [PATCH 1/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel
 Testing

Thanks for stopping by, Linus!

On 2/29/24 10:21 PM, Linus Torvalds wrote:
 > On Thu, 29 Feb 2024 at 01:23, Nikolai Kondrashov <spbnick@...il.com> wrote:
 >>
 >> However, I think a better approach would be *not* to add the .gitlab-ci.yaml
 >> file in the root of the source tree, but instead change the very same repo
 >> setting to point to a particular entry YAML, *inside* the repo (somewhere
 >> under "ci" directory) instead.
 >
 > I really don't want some kind of top-level CI for the base kernel project.
 >
 > 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 agree, it's hard to imagine even a simple majority agreeing on how GitLab CI
should be done. Still, we would like to help people, who are interested in
this kind of thing, to set it up. How about we reframe this contribution as a
sort of template, or a reference for people to start their setup with,
assuming that most maintainers would want to tweak it? We would also be glad
to stand by for questions and help, as people try to use it.

 > 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?

 > And having that slack channel that is restricted to particular
 > companies is just another sign of this whole disease.

Regarding the Slack channel, we're also on #kernelci on libera.chat, and we
have some people there, but if more people start showing up, we'll be spending
more time there too.

 > If you want to make a google/microsoft project to do kernel CI, then
 > more power to you, but don't expect it to be some kind of agreed-upon
 > kernel project when it's a closed system.

Yes, our Slack is a closed system, unfortunately. However, it's not a part of
the proposed CI setup *at all*, and it doesn't depend on Slack. We just like
using it, but we're also fine with IRC.

GitLab is open-core, and no closed-source software is required for the
proposed setup. There is the public gitlab.com where you can deploy your CI,
there's also the freedesktop.org instance, and it's possible to set up your
own (albeit not easily).

Nick