Re: [PATCH v2 0/5] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing

Nicolas Dufresne
2025-01-24T15:46:05Z

Le vendredi 24 janvier 2025 à 15:00 +0200, Laurent Pinchart a écrit :
> On Fri, Jan 24, 2025 at 01:52:03PM +0100, Mauro Carvalho Chehab wrote:
> > Em Fri, 24 Jan 2025 10:12:50 +0200 Laurent Pinchart escreveu:
> >
> > > > It's been a few years since I first thought on finding a good way of helping
> > > > kernel developers testing their patches, while making use of the free runner
> > > > minutes Gitlab offers. It can greatly simplify the testing for people who are
> > > > new to kernel development, or students trying to understand it better.
> > > >
> > > > And this patchset allows that to happen :)
> > > >
> > > > Actually, I spoke to Helen last year, and to enable it to run on the free
> > > > Gitlab-CI runners, there is a small extra patch which is needed:
> > > >
> > > > https://lore.kernel.org/all/20240327013055.139494-2-leobras@redhat.com/
> >
> > Sounds interesting!
> >
> > > Gitlab as an open-source software project (the community edition) is one
> > > thing, but can we please avoid advertising specific proprietary services
> > > in the kernel documentation ?
> >
> > Every time Gitlab is mentioned, the brand of the company that
> > developed it and has been providing proprietary services is also
> > advertised. If you're not happy with that, you should move to use
> > a git forge developed by some open source community.
>
> I'm fine mentioning the gitlab community edition, I'm not fine
> advertising gitlab.com SaaS in the kernel source tree.

I've just looked attentively, the intention is just to explain you may need to
set gitlab variable in your project fork in order to select correctly sized
sized runners in your own instance. Its is not strictly about commercial
gitlab.com instance. The default only works with the original project used
instance (which is not gitlab.com as far as I know), but the comment refer to
companies that will choose gitlab.com internally to reduce their IT cost.

Its quite a stretch to call this "advertisement", that makes it looks very
dramatic. I personally believe its quite ahead of most other gitlab CI to take
into consideration running these pipelines on foreign (to the project)
instances.

Nicolas

>
> > The way I see, the best would be if the CI integration could work
> > with more than one type of forge and being able to use any
> > free Git??b-CI runners that would be available for developers to
> > use, as this would allow testing more subsystems with CI, thus
> > increasing code quality.
>