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@xxxxxxxxxx/ > > > > > > > > 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
