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

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

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.

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

-- 
Regards,

Laurent Pinchart