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]

Date: Mon, 4 Mar 2024 18:45:33 -0300
From: Helen Koike <helen.koike@...labora.com>
To: Linus Torvalds <torvalds@...uxfoundation.org>,
 Nikolai Kondrashov <spbnick@...il.com>
Cc: Maxime Ripard <mripard@...nel.org>, 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

Hi Linus,

Thank you for your reply and valuable inputs.

On 01/03/2024 17:10, Linus Torvalds wrote:
> On Fri, 1 Mar 2024 at 02:27, Nikolai Kondrashov <spbnick@...il.com> wrote:
>>
>> 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.
> 
> Ack. I think seeing it as a library for various gitlab CI models would
> be a lot more palatable. Particularly if you can then show that yes,
> it is also relevant to our currently existing drm case.

Having it as a library would certainly make my work as the DRM-CI 
maintainer easier and  also simplify the process whenever we consider 
integrating tests into other subsystems.

> 
> So I'm not objecting to having (for example) some kind of CI helper
> templates - I think a logical place would be in tools/ci/ which is
> kind of alongside our tools/testing subdirectory.

Works for me.

We  can skip having a default .gitlab-ci.yml in the root directory and 
instead include clear instructions in our documentation for using these 
templates.

Thanks,
Helen Koike

> 
> (And then perhaps have a 'gitlab' directory under that. I'm not sure
> whether - and how much - commonality there might be between the
> different CI models of different hosts).
> 
> Just to clarify: when I say "a logical place", I very much want to
> emphasize the "a" - maybe there are better places, and I'm not saying
> that is the only possible place. But it sounds more logical to me than
> some.
> 
>              Linus