Message-ID: <d417daa2a8e3951da44bf2d555e04d98c83a3c5c.camel@collabora.com>
Date: Thu, 07 Mar 2024 13:05:12 -0500
From: Nicolas Dufresne <nicolas.dufresne@...labora.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, spbnick@...il.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

Le jeudi 29 février 2024 à 10:02 +0100, Maxime Ripard a écrit :
> 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@...hat.com>
> > Signed-off-by: Tales Aparecida <tales.aparecida@...hat.com>
> > Signed-off-by: Helen Koike <helen.koike@...labora.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?

As agreed, the .gitlab-ci.yaml file at the list will go away. Its a default
location, but not a required location. This way, each sub-system can have their
own (or not have one). The different sub-system forks will have to be configured
to point to their respective CI main configuration.

Of course nothing prevents having common set of configuration for jobs and jobs
template. As an example, we could have a job template common for checkpatch, and
allow each subsystem adding their own sauce on top. It can save the duplicate
effort of parsing the tool results and reporting it in a format gitlab
understand.

This also allow subsystems to offer different coverage, e.g. a fast vs a full
coverage. Or perhaps a configuration to focus on specific devices. But in
general, just not having a central config is enough to support the idea. What we
have now could be entirely drm specific and "commonized" later when other
subsystem wanting to use gitlab joins (Linux Media is among those).

Nicolas

Powered by blists - more mailing lists