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

Maxime Ripard <[email protected]>
Newsgroups dev.linux.lists.kernelci,org.freedesktop.lists.dri-devel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.kernel.vger.workflows
Message-ID <20240229-quizzical-persimmon-honeybee-b5db48@houat>
Hi!

On Thu, Feb 29, 2024 at 11:23:22AM +0200, Nikolai Kondrashov wrote:
> 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.

I'm interested but couldn't find it in the doc, do you have a link to
the right section?

> 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.

I'm worried that this kind of setup will just create duplicated YAML
that will be developped in complete silos and will become difficult to
maintain. But that's definitely an opinion :)

Maxime
signature.asc (application/pgp-signature, 228 B)
-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCZeBU6QAKCRDj7w1vZxhR
xQ7BAP409AbFcwBdoKD+HMuHlPoXehR+KqHJiC/xTs+iNzmyNwEAkcokR20iK1ta
dDEJ7oinWP3ncejFNUuTUwCM09uQGw0=
=Y3AM
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.