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: <5d7ed81b-37f9-48e9-ab7e-484b74ca886c@gmail.com>
Date: Thu, 29 Feb 2024 11:23:22 +0200
From: Nikolai Kondrashov <spbnick@...il.com>
To: Maxime Ripard <mripard@...nel.org>,
 Helen Koike <helen.koike@...labora.com>
Cc: 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,
 torvalds@...uxfoundation.org, gregkh@...uxfoundation.org
Subject: Re: [PATCH 1/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel
 Testing

Hi everyone,

On 2/29/24 11:02, Maxime Ripard wrote:
> On Wed, Feb 28, 2024 at 07:55:25PM -0300, Helen Koike wrote:
>> Which rating would you select?
> 
> 4.5 :)
> 
> One thing I'm wondering here is how we're going to cope with the
> different requirements each user / framework has.
> 
> Like, Linus probably want to have a different set of CI before merging a
> PR than (say) linux-next does, or stable, or before doing an actual
> release.
> 
> Similarly, DRM probably has a different set of requirements than
> drm-misc, drm-amd or nouveau.
> 
> I don't see how the current architecture could accomodate for that. I
> know that Gitlab allows to store issues template in a separate repo,
> maybe we could ask them to provide a feature where the actions would be
> separate from the main repo? That way, any gitlab project could provide
> its own set of tests, without conflicting with each others (and we could
> still share them if we wanted to)
> 
> I know some of use had good relationship with Gitlab, so maybe it would
> be worth asking?

GitLab already supports getting the CI YAML from other repos. You can change 
that in the repo settings.

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.

This way all the different subtrees can have completely different setup, but 
some could still use Helen's work and employ the "scenarios" she implemented.

Nick