From: "Leonardo Brás" <leobras.c@gmail.com>
To: Helen Koike <helen.koike@collabora.com>,
Linus Torvalds <torvalds@linuxfoundation.org>,
Nikolai Kondrashov <spbnick@gmail.com>
Cc: Maxime Ripard <mripard@kernel.org>,
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, 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,
gregkh@linuxfoundation.org
Subject: Re: [PATCH 1/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
Date: Thu, 07 Mar 2024 19:43:04 -0300 [thread overview]
Message-ID: <673ec9f4899cd1380d02bebe92d9a3d6dd7cda55.camel@gmail.com> (raw)
In-Reply-To: <17341b96-5050-4528-867a-9f628434e4e6@collabora.com>
On Mon, 2024-03-04 at 18:45 -0300, Helen Koike wrote:
> Hi Linus,
>
> Thank you for your reply and valuable inputs.
>
> On 01/03/2024 17:10, Linus Torvalds wrote:
> > On Fri, 1 Mar 2024 at 02:27, Nikolai Kondrashov <spbnick@gmail.com> wrote:
> > >
> > > I agree, it's hard to imagine even a simple majority agreeing on how GitLab CI
> > > should be done. Still, we would like to help people, who are interested in
> > > this kind of thing, to set it up. How about we reframe this contribution as a
> > > sort of template, or a reference for people to start their setup with,
> > > assuming that most maintainers would want to tweak it? We would also be glad
> > > to stand by for questions and help, as people try to use it.
> >
> > Ack. I think seeing it as a library for various gitlab CI models would
> > be a lot more palatable. Particularly if you can then show that yes,
> > it is also relevant to our currently existing drm case.
>
> Having it as a library would certainly make my work as the DRM-CI
> maintainer easier and also simplify the process whenever we consider
> integrating tests into other subsystems.
>
> >
> > So I'm not objecting to having (for example) some kind of CI helper
> > templates - I think a logical place would be in tools/ci/ which is
> > kind of alongside our tools/testing subdirectory.
>
> Works for me.
>
> We can skip having a default .gitlab-ci.yml in the root directory and
> instead include clear instructions in our documentation for using these
> templates.
From previous experience[1], I recommend this approach.
This way it does not bother current Gitlab mirrors / personal repos, while
allowing anyone to setup the CI from Gitlab menus just by changing:
Repo -> Settings -> CI/CD -> General Pipelines -> CI/CD configuration file
Thanks!
Leo
[1] Last year I implemented Gitlab-CI for the perfbook repo, and I came across
some issues, including the disruption of .gitlab-ci.yml in the root of a repo.
https://lore.kernel.org/perfbook/20230201201529.901316-1-leobras.c@gmail.com/
>
> Thanks,
> Helen Koike
>
> >
> > (And then perhaps have a 'gitlab' directory under that. I'm not sure
> > whether - and how much - commonality there might be between the
> > different CI models of different hosts).
> >
> > Just to clarify: when I say "a logical place", I very much want to
> > emphasize the "a" - maybe there are better places, and I'm not saying
> > that is the only possible place. But it sounds more logical to me than
> > some.
> >
> > Linus
next prev parent reply other threads:[~2024-03-07 22:43 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-28 22:55 [PATCH 0/3] " 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 [this message]
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
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=673ec9f4899cd1380d02bebe92d9a3d6dd7cda55.camel@gmail.com \
--to=leobras.c@gmail.com \
--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=mripard@kernel.org \
--cc=nfraprado@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