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

Nicolas Dufresne
2025-01-27T14:43:31Z

Le lundi 27 janvier 2025 à 08:07 +0200, Laurent Pinchart a écrit :
> 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.

Perhaps we can provide pointers how to run a private gitlab runner on your local
computer. My experience is that this take few minutes, unlike figuring all the
foreign bash scripts dependency, and debugging issues related to some tools not
having the right version, which inevitably lead to folks criticizing distro
choices and other counter productive discussions. Of course, it can only work if
that process is used and tested.

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