Re: [PATCH 1/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing

From: Maxime Ripard <mripard@kernel.org>
To: Helen Koike <helen.koike@collabora.com>
Cc: linuxtv-ci@linuxtv.org, dave.pigott@collabora.com,
	 linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
	linux-kselftest@vger.kernel.org,  gustavo.padovan@collabora.com,
	pawiecz@collabora.com, spbnick@gmail.com,
	 tales.aparecida@gmail.com, workflows@vger.kernel.org,
	kernelci@lists.linux.dev,  skhan@linuxfoundation.org,
	kunit-dev@googlegroups.com, nfraprado@collabora.com,
	 davidgow@google.com, cocci@inria.fr, Julia.Lawall@inria.fr,
	laura.nao@collabora.com,  ricardo.canuelo@collabora.com,
	kernel@collabora.com, torvalds@linuxfoundation.org,
	 gregkh@linuxfoundation.org
Subject: Re: [PATCH 1/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
Date: Thu, 29 Feb 2024 10:02:11 +0100	[thread overview]
Message-ID: <20240229-dancing-laughing-groundhog-d85161@houat> (raw)
In-Reply-To: <20240228225527.1052240-2-helen.koike@collabora.com>

[-- Attachment #1: Type: text/plain, Size: 2510 bytes --]

Hi Helen,

Thanks for working on this

On Wed, Feb 28, 2024 at 07:55:25PM -0300, Helen Koike wrote:
> This patch introduces a `.gitlab-ci` file along with a `ci/` folder,
> defininga basic test pipeline triggered by code pushes to a GitLab-CI
> instance. This initial version includes static checks (checkpatch and
> smatch for now) and build tests across various architectures and
> configurations. It leverages an integrated cache for efficient build
> times and introduces a flexible 'scenarios' mechanism for
> subsystem-specific extensions.
> 
> [ci: add prerequisites to run check-patch on MRs]
> Co-developed-by: Tales Aparecida <tales.aparecida@redhat.com>
> Signed-off-by: Tales Aparecida <tales.aparecida@redhat.com>
> Signed-off-by: Helen Koike <helen.koike@collabora.com>
> 
> ---
> 
> Hey all,
> 
> You can check the validation of this patchset on:
>         https://gitlab.collabora.com/koike/linux/-/pipelines/87035
> 
> I would appreciate your feedback on this work, what do you think?
> 
> If you would rate from 0 to 5, where:
> 
> [ ] 0. I don't think this is useful at all, and I doubt it will ever be. It doesn't seem worthwhile.
> [ ] 1. I don't find it useful in its current form.
> [ ] 2. It might be useful to others, but not for me.
> [ ] 3. It has potential, but it's not yet something I can incorporate into my workflow.
> [ ] 4. This is useful, but it needs some adjustments before I can include it in my workflow.
> [ ] 5. This is really useful! I'm eager to start using it right away. Why didn't you send this earlier? :)
> 
> 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?

Maxime

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]