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: Thu, 07 Mar 2024 19:43:04 -0300
From: Leonardo Brás <leobras.c@...il.com>
To: Helen Koike <helen.koike@...labora.com>, 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

On Mon, 2024-03-04 at 18:45 -0300, Helen Koike wrote:
> 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.

>From previous experience[1], I recommend this approach.

This way it does not bother current Gitlab mirrors / personal repos, while
allowing anyone to setup the CI from Gitlab menus just by changing:

Repo -> Settings -> CI/CD -> General Pipelines -> CI/CD configuration file

Thanks!
Leo

[1] Last year I implemented Gitlab-CI for the perfbook repo, and I came across
some issues, including the disruption of .gitlab-ci.yml in the root of a repo.
https://lore.kernel.org/perfbook/20230201201529.901316-1-leobras.c@gmail.com/

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