Received-SPF: pass (google.com: domain of linux-kernel+bounces-86364-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:4601:e00::3 as permitted sender) client-ip=2604:1380:4601:e00::3;
Date: Thu, 29 Feb 2024 10:02:11 +0100
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
Message-ID: <20240229-dancing-laughing-groundhog-d85161@houat>
References: <20240228225527.1052240-1-helen.koike@collabora.com>
 <20240228225527.1052240-2-helen.koike@collabora.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="brdohharmqyoi5zz"
Content-Disposition: inline
In-Reply-To: <20240228225527.1052240-2-helen.koike@collabora.com>


--brdohharmqyoi5zz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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.
>=20
> [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>
>=20
> ---
>=20
> Hey all,
>=20
> You can check the validation of this patchset on:
>         https://gitlab.collabora.com/koike/linux/-/pipelines/87035
>=20
> I would appreciate your feedback on this work, what do you think?
>=20
> If you would rate from 0 to 5, where:
>=20
> [ ] 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 int=
o 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? :)
>=20
> 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

--brdohharmqyoi5zz
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCZeBIEgAKCRDj7w1vZxhR
xSjBAQCRssfillRrGUMBa1ch3HBDzvSfbSqZ2N/SJfWL+UZbAwEAsIDU0lgkUX70
nn5+H8DQwoNMV2PnoT2QpRTKqGauPwY=
=mmaE
-----END PGP SIGNATURE-----

--brdohharmqyoi5zz--