[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d99d026e-ed32-4432-bab3-db75296e67d8@gtucker.io>
Date: Thu, 29 Feb 2024 13:20:41 +0100
From: Guillaume Tucker <gtucker@...cker.io>
To: Helen Koike <helen.koike@...labora.com>, linuxtv-ci@...uxtv.org,
dave.pigott@...labora.com, mripard@...nel.org, linux-kernel@...r.kernel.org,
dri-devel@...ts.freedesktop.org, linux-kselftest@...r.kernel.org,
gustavo.padovan@...labora.com, pawiecz@...labora.com, spbnick@...il.com,
tales.aparecida@...il.com, workflows@...r.kernel.org,
kernelci@...ts.linux.dev, skhan@...uxfoundation.org,
kunit-dev@...glegroups.com, nfraprado@...labora.com, davidgow@...gle.com,
cocci@...ia.fr, Julia.Lawall@...ia.fr, laura.nao@...labora.com,
ricardo.canuelo@...labora.com, kernel@...labora.com,
torvalds@...uxfoundation.org, gregkh@...uxfoundation.org
Subject: Re: [PATCH 0/3] kci-gitlab: Introducing GitLab-CI Pipeline for Kernel
Testing
Hello,
On 28/02/2024 23:55, Helen Koike wrote:
> Dear Kernel Community,
>
> This patch introduces a `.gitlab-ci` file along with a `ci/` folder, defining a
> basic test pipeline triggered by code pushes to a GitLab-CI instance. This
> initial version includes static checks (checkpatch and smatch for now) and build
> tests across various architectures and configurations. It leverages an
> integrated cache for efficient build times and introduces a flexible 'scenarios'
> mechanism for subsystem-specific extensions.
This sounds like a nice starting point to me as an additional way
to run tests upstream. I have one particular question as I see a
pattern through the rest of the email, please see below.
[...]
> 4. **Collaborative Testing Environment:** The kernel community is already
> engaged in numerous testing efforts, including various GitLab-CI pipelines such
> as DRM-CI, which I maintain, along with other solutions like KernelCI and
> BPF-CI. This proposal is designed to further stimulate contributions to the
> evolving testing landscape. Our goal is to establish a comprehensive suite of
> common tools and files.
[...]
> **Leveraging External Test Labs:**
> We can extend our testing to external labs, similar to what DRM-CI currently
> does. This includes:
> - Lava labs
> - Bare metal labs
> - Using KernelCI-provided labs
>
> **Other integrations**
> - Submit results to KCIDB
[...]
> **Join Our Slack Channel:**
> We have a Slack channel, #gitlab-ci, on the KernelCI Slack instance https://kernelci.slack.com/ .
> Feel free to join and contribute to the conversation. The KernelCI team has
> weekly calls where we also discuss the GitLab-CI pipeline.
>
> **Acknowledgments:**
> A special thanks to Nikolai Kondrashov, Tales da Aparecida - both from Red Hat -
> and KernelCI community for their valuable feedback and support in this proposal.
Where does this fit on the KernelCI roadmap?
I see it mentioned a few times but it's not entirely clear
whether this initiative is an independent one or in some way
linked to KernelCI. Say, are you planning to use the kci tool,
new API, compiler toolchains, user-space and Docker images etc?
Or, are KernelCI plans evolving to follow this move?
Thanks,
Guillaume
Powered by blists - more mailing lists