Re: [PATCH 1/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
Helen Koike <[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]> |
Hi Linus, Thank you for your reply and valuable inputs. On 01/03/2024 17:10, Linus Torvalds wrote: > On Fri, 1 Mar 2024 at 02:27, Nikolai Kondrashov <[email protected]> wrote: >> >> I agree, it's hard to imagine even a simple majority agreeing on how GitLab CI >> should be done. Still, we would like to help people, who are interested in >> this kind of thing, to set it up. How about we reframe this contribution as a >> sort of template, or a reference for people to start their setup with, >> assuming that most maintainers would want to tweak it? We would also be glad >> to stand by for questions and help, as people try to use it. > > Ack. I think seeing it as a library for various gitlab CI models would > be a lot more palatable. Particularly if you can then show that yes, > it is also relevant to our currently existing drm case. Having it as a library would certainly make my work as the DRM-CI maintainer easier and also simplify the process whenever we consider integrating tests into other subsystems. > > So I'm not objecting to having (for example) some kind of CI helper > templates - I think a logical place would be in tools/ci/ which is > kind of alongside our tools/testing subdirectory. Works for me. We can skip having a default .gitlab-ci.yml in the root directory and instead include clear instructions in our documentation for using these templates. Thanks, Helen Koike > > (And then perhaps have a 'gitlab' directory under that. I'm not sure > whether - and how much - commonality there might be between the > different CI models of different hosts). > > Just to clarify: when I say "a logical place", I very much want to > emphasize the "a" - maybe there are better places, and I'm not saying > that is the only possible place. But it sounds more logical to me than > some. > > Linus