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

["Leonardo Brás" <leobras.c@gmail.com>]

On Fri, 2025-01-24 at 10:45 -0500, Nicolas Dufresne wrote:
> 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.

Hello Laurent,

I see your point, and I see no issue on removing the two last lines of CI_TAGS
documentation.

I just added this information on documentation because the default runner used
for the Free Tier of Gitlab does not work for this CI, as it needs more
resources to run. This information can be added on some other place, but at the
time I thought it would be ok to let it be there. 
This other runner I mentioned in the patch is also available on the Free Tier
(free as in beer).

I would like to make it clear that I have no connection/affiliation to Gitlab,
other than a free account in their system, which I use for some CI. I have no
interest on advertising anything from them.

My only objective is to make it easier to hobbyists/beginners to use those
available free minutes to test some change before sending the patch, if they
think that's valuable.

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

That's correct

>  Its is not strictly about commercial gitlab.com instance. 

Exactly, the change is about being able to choose the runner you want.

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

Correct.
Companies can benefit on that, but my focus was on hobbyist (or begginers) who
may want to test their patches on free CI before sending them to the ML.

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

Thank you!
Leo

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