From: Maxime Ripard <mripard@kernel.org>
To: Nicolas Dufresne <nicolas.dufresne@collabora.com>
Cc: Helen Koike <helen.koike@collabora.com>,
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: Mon, 11 Mar 2024 09:40:02 +0100 [thread overview]
Message-ID: <20240311-electric-cream-hippo-20eada@houat> (raw)
In-Reply-To: <d417daa2a8e3951da44bf2d555e04d98c83a3c5c.camel@collabora.com>
[-- Attachment #1: Type: text/plain, Size: 3553 bytes --]
Hi Nicolas,
On Thu, Mar 07, 2024 at 01:05:12PM -0500, Nicolas Dufresne wrote:
> Le jeudi 29 février 2024 à 10:02 +0100, Maxime Ripard a écrit :
> > 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?
>
> 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.
That makes total sense to me and would be incredibly useful indeed.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2024-03-11 8:40 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-28 22:55 [PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing Helen Koike
2024-02-28 22:55 ` [PATCH 1/3] " Helen Koike
2024-02-29 2:44 ` Bird, Tim
2024-02-29 16:15 ` Nicolas Dufresne
2024-02-29 9:02 ` Maxime Ripard
2024-02-29 9:23 ` Nikolai Kondrashov
2024-02-29 9:56 ` Maxime Ripard
2024-02-29 10:05 ` Laurent Pinchart
2024-02-29 20:21 ` Linus Torvalds
2024-03-01 10:27 ` Nikolai Kondrashov
2024-03-01 14:07 ` Mark Brown
2024-03-01 14:21 ` Nikolai Kondrashov
2024-03-01 20:10 ` Linus Torvalds
2024-03-04 21:45 ` Helen Koike
2024-03-07 22:43 ` Leonardo Brás
2024-05-23 13:21 ` Daniel Vetter
2024-03-02 22:10 ` Guenter Roeck
2024-03-03 0:01 ` Randy Dunlap
2024-03-03 9:30 ` Geert Uytterhoeven
2024-03-04 8:12 ` Geert Uytterhoeven
2024-03-04 9:15 ` Maxime Ripard
2024-03-04 10:07 ` Geert Uytterhoeven
2024-03-04 10:19 ` Maxime Ripard
2024-03-04 11:12 ` Geert Uytterhoeven
2024-03-04 11:28 ` Maxime Ripard
2024-03-04 9:24 ` Maxime Ripard
2024-03-04 15:46 ` Guenter Roeck
2024-03-04 16:05 ` Maxime Ripard
2024-03-04 16:17 ` Guenter Roeck
2024-03-04 17:09 ` Maxime Ripard
2024-03-04 17:22 ` Guenter Roeck
2024-03-04 19:44 ` Guenter Roeck
2024-03-05 11:54 ` Michel Dänzer
2024-03-07 18:05 ` Nicolas Dufresne
2024-03-11 8:40 ` Maxime Ripard [this message]
2024-02-28 22:55 ` [PATCH 2/3] kci-gitlab: Add documentation Helen Koike
2024-02-28 22:55 ` [PATCH 3/3] kci-gitlab: docs: Add images Helen Koike
2024-02-28 23:07 ` [PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing Laurent Pinchart
2024-02-29 8:43 ` Maxime Ripard
2024-02-29 9:26 ` Nikolai Kondrashov
2024-02-29 9:34 ` Laurent Pinchart
2024-02-29 11:10 ` Nikolai Kondrashov
2024-02-29 11:19 ` Laurent Pinchart
2024-02-29 11:22 ` Nikolai Kondrashov
2024-02-29 11:41 ` Mark Brown
2024-02-29 11:53 ` Guillaume Tucker
2024-02-29 12:20 ` Laurent Pinchart
2024-02-29 12:25 ` Laurent Pinchart
2024-02-29 14:12 ` Nikolai Kondrashov
2024-02-29 9:39 ` Sakari Ailus
2024-02-29 11:09 ` Mark Brown
2024-02-29 12:20 ` Guillaume Tucker
2024-02-29 14:16 ` Nikolai Kondrashov
2024-02-29 16:28 ` Nicolas Dufresne
2024-03-01 21:56 ` Guillaume Tucker
2024-03-02 21:48 ` Gustavo Padovan
2024-03-04 8:33 ` Guillaume Tucker
2024-05-21 9:28 ` Jarkko Sakkinen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240311-electric-cream-hippo-20eada@houat \
--to=mripard@kernel.org \
--cc=Julia.Lawall@inria.fr \
--cc=cocci@inria.fr \
--cc=dave.pigott@collabora.com \
--cc=davidgow@google.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gregkh@linuxfoundation.org \
--cc=gustavo.padovan@collabora.com \
--cc=helen.koike@collabora.com \
--cc=kernel@collabora.com \
--cc=kernelci@lists.linux.dev \
--cc=kunit-dev@googlegroups.com \
--cc=laura.nao@collabora.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linuxtv-ci@linuxtv.org \
--cc=nfraprado@collabora.com \
--cc=nicolas.dufresne@collabora.com \
--cc=pawiecz@collabora.com \
--cc=ricardo.canuelo@collabora.com \
--cc=skhan@linuxfoundation.org \
--cc=spbnick@gmail.com \
--cc=tales.aparecida@gmail.com \
--cc=torvalds@linuxfoundation.org \
--cc=workflows@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).