Message-ID: <20250127080618.55f5f915@foz.lan>
Date: Mon, 27 Jan 2025 08:07:03 +0100
From: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To: Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc: Leonardo Brás <leobras.c@...il.com>, Nicolas Dufresne
 <nicolas.dufresne@...labora.com>, Vignesh Raman
 <vignesh.raman@...labora.com>, kernelci@...ts.linux.dev,
 linuxtv-ci@...uxtv.org, dave.pigott@...labora.com, mripard@...nel.org,
 linux-kernel@...r.kernel.org, dri-devel@...ts.freedesktop.org,
 linux-kselftest@...r.kernel.org, pawiecz@...labora.com,
 tales.aparecida@...il.com, workflows@...r.kernel.org,
 kunit-dev@...glegroups.com, nfraprado@...labora.com, davidgow@...gle.com,
 cocci@...ia.fr, Julia.Lawall@...ia.fr, kernel@...labora.com,
 torvalds@...uxfoundation.org, gregkh@...uxfoundation.org,
 daniels@...labora.com, shreeya.patel@...labora.com, denys.f@...labora.com,
 louis.chauvet@...tlin.com, hamohammed.sa@...il.com, melissa.srw@...il.com,
 simona@...ll.ch, airlied@...il.com, Tim.Bird@...y.com, broonie@...nel.org,
 groeck@...gle.com, rdunlap@...radead.org, geert@...ux-m68k.org,
 michel.daenzer@...lbox.org, sakari.ailus@....fi, jarkko@...nel.org
Subject: Re: [PATCH v2 0/5] kci-gitlab: Introducing GitLab-CI Pipeline for
 Kernel Testing

Em Mon, 27 Jan 2025 08:07:38 +0200
Laurent Pinchart <laurent.pinchart@...asonboard.com> escreveu:

> On Fri, Jan 24, 2025 at 06:12:24PM -0300, Leonardo Brás wrote:
> > 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.  
> 
> Given the 400 free computes minute per month, and the fact that the
> saas-linux-medium-amd64 runner consumers two minutes per minute, how
> many of the proposed CI runs would be available per month ?
> 
> CI pipeline runs always compile the kernel from scratch as far as  can
> see. This may not be an issue for final testing before submission of a
> patch series, but it just won't work for incremental testing of changes.
> Think of how inefficient it would be to run a full pipeline just to get
> the checkpatch.pl output for instance. This is why I believe tests
> should focus first and foremost on ease of use in developers' local
> environments. A standardized, from-scratch, comprehensive test run as a
> gate keeper for integration has value as well, but that won't help
> beginners much.

To better cope with free minutes, CI pipelines should allow setting
up build just the subsystem instead of the entire Kernel. Not perfect,
but still if CI would test multiple archs/Kconfig options, it would
be useful to get early lots of potential issues.

That's said, using developers' local environments is interesting.
Yet, there's s potential risk of using it while having an external
entity running a git forge, as it would mean that a remote entity
would trigger something to run locally. Personally, I would 

So, if I were to setup a local build environment, I would either use
a separate machine outside my internal network or I would opt to
install a local git forge instance. No idea how easy/hard would
be to maintain such local gitlab instance.

Thanks,
Mauro

Powered by blists - more mailing lists