Re: [PATCH 1/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing

Randy Dunlap <[email protected]>
Newsgroups dev.linux.lists.kernelci,org.freedesktop.lists.dri-devel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-kselftest,org.kernel.vger.workflows
Message-ID <[email protected]>

On 3/2/24 14:10, Guenter Roeck wrote:
> On Thu, Feb 29, 2024 at 12:21 PM Linus Torvalds
> <[email protected]> wrote:
>>
>> On Thu, 29 Feb 2024 at 01:23, Nikolai Kondrashov <[email protected]> wrote:
>>>
>>> However, I think a better approach would be *not* to add the .gitlab-ci.yaml
>>> file in the root of the source tree, but instead change the very same repo
>>> setting to point to a particular entry YAML, *inside* the repo (somewhere
>>> under "ci" directory) instead.
>>
>> I really don't want some kind of top-level CI for the base kernel project.
>>
>> We already have the situation that the drm people have their own ci
>> model. II'm ok with that, partly because then at least the maintainers
>> of that subsystem can agree on the rules for that one subsystem.
>>
>> I'm not at all interested in having something that people will then
>> either fight about, or - more likely - ignore, at the top level
>> because there isn't some global agreement about what the rules are.
>>
>> For example, even just running checkpatch is often a stylistic thing,
>> and not everybody agrees about all the checkpatch warnings.
>>
> 
> While checkpatch is indeed of arguable value, I think it would help a
> lot not having to bother about the persistent _build_ failures on
> 32-bit systems. You mentioned the fancy drm CI system above, but they
> don't run tests and not even test builds on 32-bit targets, which has
> repeatedly caused (and currently does cause) build failures in drm
> code when trying to build, say, arm:allmodconfig in linux-next. Most
> trivial build failures in linux-next (and, yes, sometimes mainline)
> could be prevented with a simple generic CI.

Yes, definitely. Thanks for bringing that up.

> Sure, argue against checkpatch as much as you like, but the code
> should at least _build_, and it should not be necessary for random
> people to report build failures to the submitters.

I do 110 randconfig builds nightly (10 each of 11 $ARCH/$BITS).
That's about all the horsepower that I have. and I am not a CI.  :)

So I see quite a bit of what you are saying. It seems that Arnd is
in the same boat.

-- 
#Randy
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.