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]
Date: Fri, 1 Mar 2024 16:21:13 +0200
From: Nikolai Kondrashov <spbnick@...il.com>
To: Mark Brown <broonie@...nel.org>
Cc: Linus Torvalds <torvalds@...uxfoundation.org>,
 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

On 3/1/24 4:07 PM, Mark Brown wrote:
> On Fri, Mar 01, 2024 at 12:27:13PM +0200, Nikolai Kondrashov wrote:
>> On 2/29/24 10:21 PM, Linus Torvalds wrote:
>>> 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.

Yes, facilitating reuse and collaboration between CI setups, even if they're 
largely different, is another good reason to have it inside the kernel repo.

Nick

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ