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: <a77f2eea-1793-4e83-92b0-92b5bbd23a5e@redhat.com>
Date: Fri, 24 Jan 2025 14:58:14 +0200
From: Nikolai Kondrashov <Nikolai.Kondrashov@...hat.com>
To: Jarkko Sakkinen <jarkko@...nel.org>,
 Vignesh Raman <vignesh.raman@...labora.com>, kernelci@...ts.linux.dev
Cc: linuxtv-ci@...uxtv.org, dave.pigott@...labora.com, mripard@...nel.org,
 linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
 linux-kselftest@...r.kernel.org, gustavo.padovan@...labora.com,
 pawiecz@...labora.com, spbnick@...il.com, tales.aparecida@...il.com,
 workflows@...r.kernel.org, skhan@...uxfoundation.org,
 kunit-dev@...glegroups.com, nfraprado@...labora.com, davidgow@...gle.com,
 cocci@...ia.fr, Julia.Lawall@...ia.fr, laura.nao@...labora.com,
 kernel@...labora.com, torvalds@...uxfoundation.org,
 gregkh@...uxfoundation.org, daniels@...labora.com,
 helen.koike@...labora.com, shreeya.patel@...labora.com,
 denys.f@...labora.com, nicolas.dufresne@...labora.com,
 louis.chauvet@...tlin.com, hamohammed.sa@...il.com, melissa.srw@...il.com,
 simona@...ll.ch, airlied@...il.com, Tim.Bird@...y.com,
 laurent.pinchart@...asonboard.com, broonie@...nel.org, leobras.c@...il.com,
 groeck@...gle.com, rdunlap@...radead.org, geert@...ux-m68k.org,
 michel.daenzer@...lbox.org, sakari.ailus@....fi
Subject: Re: [PATCH v2 0/5] kci-gitlab: Introducing GitLab-CI Pipeline for
 Kernel Testing

Hi Jarkko,

On 1/23/25 11:30 PM, Jarkko Sakkinen wrote:
> On Thu Jan 23, 2025 at 3:53 PM EET, Vignesh Raman wrote:
>> We are working towards creating a generic, upstream GitLab-CI pipeline
>> (kci-gitlab) that will replace DRM-CI [1]. The proposed GitLab-CI pipeline
>> is designed with a distributed infrastructure model, making it possible
>> to run on any gitLab instance. We plan to leverage KernelCI [2] as the
>> backend, utilizing its hardware, rootfs, test plans, and KCIDB [3]
>> integration.
> 
> Why can't you keep the next version of your great pipeline outside the
> kernel tree?
> 
> If there is a legit motivation for doing that, why it needs to be bound
> to Gitlab? Why can't you make script callable from any CI?

Greetings from the (today's) sunny Espoo!

Of course we could keep it outside the kernel tree. However, the point of this
contribution is to provide kernel maintainers and developers with an easy way
to setup their CI pipeline on a GitLab instance (the main one, FreeDesktop
one, or any other). Basically this is like a template or a library, if you
wish, which helps you do that. Approved by Linus too.

Why GitLab? Because it's one of the best, if not *the* best CI system these
days, with lots of flexibility, and it's Open-Source too (well, at least
open-core, which is still very capable). And also because a number of
maintainers and companies are already using it.

Sure, a script could be contributed too, but the value of this contribution is
a ready-made integration. And we want to make it easily discoverable, and
easily contributed to.

BTW, here's the talk we gave at last year's LPC regarding current use of
GitLab in the kernel and surrounding community:

https://lpc.events/event/18/contributions/1728/

Nick


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ