Hi Jarkko, On 1/24/25 6:32 PM, Jarkko Sakkinen wrote: > On Fri Jan 24, 2025 at 2:58 PM EET, Nikolai Kondrashov wrote: >> Of course we could keep it outside the kernel tree. However, the point of this >> contribution is to provide kernel maintainers and developers with an easy way >> to setup their CI pipeline on a GitLab instance (the main one, FreeDesktop >> one, or any other). Basically this is like a template or a library, if you >> wish, which helps you do that. Approved by Linus too. > > With all due respect, "approved by Linus" is not an argument :-) I get > that Linus can make the "ultimate decision" but in argumentation I'm not > a strong believer of authority based decision making process. Not > downplaying this more than that I knowingly ignore this comment. Sure, fair enough! >> Why GitLab? Because it's one of the best, if not *the* best CI system these >> days, with lots of flexibility, and it's Open-Source too (well, at least >> open-core, which is still very capable). And also because a number of >> maintainers and companies are already using it. > > There's also Github Runners and Woodpecker CI used by Codeberg. To add, > some companies and other organizations prefer Jenkins. This one fit for > all strategy is somewhat short-sighted. We're not suggesting everyone should use this. We've just been using it, know it well, know it works, and so are trying to help people use it. Please feel free to use something else, and of course contribute the corresponding CI setup to the kernel repo! Not that I can stop anyone, of course, but that's the idea behind this. Note the "/ci/gitlab-ci/" path. Anything which could help maintainers/developers integrate testing with their development workflow cango under "/ci/", I think. > Also running Gitlab tasks locally is possible but is heavy-lifting. Yeah, it's not perfect. > Can we then agree that any CI changes can be sent untested to LKML if > a patch set needs to reflect on those? It's not reasonable to except > local runs Gitlab from individuals for patch sets. It makes our lives > more difficult, not easier. This is not really for individual contributors, but for maintainers/subsystems to help automate their team's (and contributor's) testing. And this is not saying you're required to run GitLab CI for your contribution. It's up to a particular subsystem to decide their policies: whether to just have the maintainers send contributions off to a GitLab CI instance during review, or larger merges, give co-maintainers access to it, or require contributors to submit an (automatically-tested) MR. If you send patches changing CI, then of course you're expected to test it, as with any contribution to any project. But if you're not running it, why would you do that? And if you or the recipient maintainer run it, then you get it tested automatically. > All maintainers I know test their patches for the most part with > BuildRoot, distro VM's and stuff like that. Not claiming that they > don't exist, but never heard of kernel maintainer who uses Gitlab > as their main kernel testing tool. Well, some of the people in this discussion do that, and more are mentioned in that talk I linked. But sure, I think contributing their setups to the kernel tree would help others who want to automate their testing. >> Sure, a script could be contributed too, but the value of this contribution is >> a ready-made integration. And we want to make it easily discoverable, and >> easily contributed to. > > This is definitely NOT "lots of flexibility". > > Are you dead seriously claiming that DevOps engineers could not handle > well defined CI scripts and bind to whatever CI makes sense to them? > o_O No, of course not. This is simply to make life easier for maintainers, who are not necessarily DevOps engineers themselves, and want to try it out, or have it setup. Of course, having well-defined CI scripts would be great, and we enjoy e.g. well-defined make interface in CI, for example. I assume engineers who implemented this (Helen et al.) would be happy to use such a script, if it existed and was suitable. The problem is that it would still need to interface with GitLab CI, which is while flexible, suffers the flip-side problem of being complex. And that's where the devil is, and this contribution is trying to help defeat it. >> BTW, here's the talk we gave at last year's LPC regarding current use of >> GitLab in the kernel and surrounding community: >> >> https://lpc.events/event/18/contributions/1728/ > > This patch set should make the case, not an old presentation. Well, I'm sure there are angles not covered by the cover letter and commit messages of this contribution, and I'm partially to blame, as I was one of the pre-reviewers. However, I'm sure we have left more stuff uncovered than we discuss here, even considering the discussion of the first version. And so I provided the link to the talk as a rectification. But if it would help, I can provide a summary of it here too. Nick
