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

5 views
Skip to first unread message

Helen Koike

unread,
Feb 28, 2024, 5:55:41 PMFeb 28
to linux...@linuxtv.org, dave....@collabora.com, mri...@kernel.org, linux-...@vger.kernel.org, dri-...@lists.freedesktop.org, linux-k...@vger.kernel.org, gustavo...@collabora.com, paw...@collabora.com, spb...@gmail.com, tales.a...@gmail.com, work...@vger.kernel.org, kern...@lists.linux.dev, sk...@linuxfoundation.org, kuni...@googlegroups.com, nfra...@collabora.com, davi...@google.com, co...@inria.fr, Julia....@inria.fr, laur...@collabora.com, ricardo...@collabora.com, ker...@collabora.com, torv...@linuxfoundation.org, gre...@linuxfoundation.org
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.

tl;dr: check this video to see a quick demo: https://youtu.be/TWiTjhjOuzg,
but don't forget to check the "Motivation for this work" below. Your feedback,
whether a simple thumbs up or down, is crucial to determine if it is worthwhile
to pursue this initiative.

GitLab is an Open Source platform that includes integrated CI/CD. The pipeline
provided in this patch is designed to work out-of-the-box with any GitLab
instance, including the gitlab.com Free Tier. If you reach the limits of the
Free Tier, consider using community instances like https://gitlab.freedesktop.org/.
Alternatively, you can set up a local runner for more flexibility. The
bootstrap-gitlab-runner.sh script included with this patch simplifies this
process, enabling you to run tests on your preferred infrastructure, including
your own machine.

For detailed information, please refer to the documentation included in the
patch, or check the rendered version here: https://koike.pages.collabora.com/-/linux/-/jobs/298498/artifacts/artifacts/Documentation-output/ci/gitlab-ci/gitlab-ci.html .


Motivation for this Work
========================

We all know tests are a major topic in the community, so let's mention the
specificities of this approach:

1. **Built-in User Interface:** GitLab CI/CD is growing in popularity and has an
user-friendly interface. Our experience with the upstream DRM-CI in the kernel
tree (see this blog post [https://www.collabora.com/news-and-blog/blog/2024/02/08/drm-ci-a-gitlab-ci-pipeline-for-linux-kernel-testing/] )
has provided insights into how such a system can benefit the wider community.

2. **Distributed Infrastructure:**
The proposed GitLab-CI pipeline is designed with a distributed infrastructure
model, being possible to run in any gitlab instance.

3. **Reduce regressions:** Fostering a culture where people habitually run
validated tests and post their results can prevent many issues in post-merge
tests.

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.

5. **Ownership of QA:**
Discrepancies between kernel code and outdated tests often lead to misattributed
failures, complicating regression tracking. This issue, often arising from
neglected or deprioritized test updates, creates uncertainty about the source of
failures. Adopting an "always green pipeline" approach, as detailed in this
patch's documentation, encourages timely maintenance and validation of tests.
This ensures that testing accurately reflects the current state of the kernel,
thereby improving the effectiveness of our QA processes.

Additionally, if we discover that this method isn't working for us, we can
easily remove it from the codebase, as it is primarily contained within the ci/
folder.


Future Work
===========

**Expanding Static Checks:**
We have the opportunity to integrate a variety of static analysis tools,
including:
- dtbs_checks
- sparse
- yamllint
- dt-doc-validate
- coccicheck

**Adding Userspace Tests on VMs:**
To further our testing, we can implement userspace tests that run on virtual
machines (VMs), such as:
- kselftests
- kunit tests
- Subsystem-specific tests, customizable in the scenarios.

**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

**Lightweight Implementation for All Developers:**
We aim to design these tests to be lightweight, ensuring developers with limited
computing resources can still run essential tests. Resource-intensive tests can
be set to trigger manually, rather than automatically, to accommodate diverse
development environments.


Chat Discussions
================

For those interested in further discussions:

**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.


I eagerly await your thoughts and suggestions on this initiative.

Also, if you want to see this initiave move faster, we are happy to discuss
funding options.

Best regards,
Helen Koike

Helen Koike (3):
kci-gitlab: Introducing GitLab-CI Pipeline for Kernel Testing
kci-gitlab: Add documentation
kci-gitlab: docs: Add images

.gitlab-ci.yml | 2 +
Documentation/ci/gitlab-ci/gitlab-ci.rst | 404 ++++++++++++++++++
.../ci/gitlab-ci/images/job-matrix.png | Bin 0 -> 159752 bytes
.../gitlab-ci/images/new-project-runner.png | Bin 0 -> 607737 bytes
.../ci/gitlab-ci/images/pipelines-on-push.png | Bin 0 -> 532143 bytes
.../ci/gitlab-ci/images/the-pipeline.png | Bin 0 -> 91675 bytes
.../ci/gitlab-ci/images/variables.png | Bin 0 -> 277518 bytes
Documentation/index.rst | 7 +
MAINTAINERS | 9 +
ci/gitlab-ci/bootstrap-gitlab-runner.sh | 55 +++
ci/gitlab-ci/ci-scripts/build-docs.sh | 35 ++
ci/gitlab-ci/ci-scripts/build-kernel.sh | 35 ++
ci/gitlab-ci/ci-scripts/ici-functions.sh | 104 +++++
ci/gitlab-ci/ci-scripts/install-smatch.sh | 13 +
.../ci-scripts/parse_commit_message.sh | 27 ++
ci/gitlab-ci/ci-scripts/run-checkpatch.sh | 19 +
ci/gitlab-ci/ci-scripts/run-smatch.sh | 45 ++
ci/gitlab-ci/docker-compose.yaml | 18 +
ci/gitlab-ci/linux.code-workspace | 11 +
ci/gitlab-ci/yml/build.yml | 43 ++
ci/gitlab-ci/yml/cache.yml | 26 ++
ci/gitlab-ci/yml/container.yml | 36 ++
ci/gitlab-ci/yml/gitlab-ci.yml | 71 +++
ci/gitlab-ci/yml/kernel-combinations.yml | 18 +
ci/gitlab-ci/yml/scenarios.yml | 12 +
ci/gitlab-ci/yml/scenarios/file-systems.yml | 21 +
ci/gitlab-ci/yml/scenarios/media.yml | 21 +
ci/gitlab-ci/yml/scenarios/network.yml | 21 +
ci/gitlab-ci/yml/static-checks.yml | 21 +
29 files changed, 1074 insertions(+)
create mode 100644 .gitlab-ci.yml
create mode 100644 Documentation/ci/gitlab-ci/gitlab-ci.rst
create mode 100644 Documentation/ci/gitlab-ci/images/job-matrix.png
create mode 100644 Documentation/ci/gitlab-ci/images/new-project-runner.png
create mode 100644 Documentation/ci/gitlab-ci/images/pipelines-on-push.png
create mode 100644 Documentation/ci/gitlab-ci/images/the-pipeline.png
create mode 100644 Documentation/ci/gitlab-ci/images/variables.png
create mode 100755 ci/gitlab-ci/bootstrap-gitlab-runner.sh
create mode 100755 ci/gitlab-ci/ci-scripts/build-docs.sh
create mode 100755 ci/gitlab-ci/ci-scripts/build-kernel.sh
create mode 100644 ci/gitlab-ci/ci-scripts/ici-functions.sh
create mode 100755 ci/gitlab-ci/ci-scripts/install-smatch.sh
create mode 100755 ci/gitlab-ci/ci-scripts/parse_commit_message.sh
create mode 100755 ci/gitlab-ci/ci-scripts/run-checkpatch.sh
create mode 100755 ci/gitlab-ci/ci-scripts/run-smatch.sh
create mode 100644 ci/gitlab-ci/docker-compose.yaml
create mode 100644 ci/gitlab-ci/linux.code-workspace
create mode 100644 ci/gitlab-ci/yml/build.yml
create mode 100644 ci/gitlab-ci/yml/cache.yml
create mode 100644 ci/gitlab-ci/yml/container.yml
create mode 100644 ci/gitlab-ci/yml/gitlab-ci.yml
create mode 100644 ci/gitlab-ci/yml/kernel-combinations.yml
create mode 100644 ci/gitlab-ci/yml/scenarios.yml
create mode 100644 ci/gitlab-ci/yml/scenarios/file-systems.yml
create mode 100644 ci/gitlab-ci/yml/scenarios/media.yml
create mode 100644 ci/gitlab-ci/yml/scenarios/network.yml
create mode 100644 ci/gitlab-ci/yml/static-checks.yml

--
2.40.1

Helen Koike

unread,
Feb 28, 2024, 5:55:48 PMFeb 28
to linux...@linuxtv.org, dave....@collabora.com, mri...@kernel.org, linux-...@vger.kernel.org, dri-...@lists.freedesktop.org, linux-k...@vger.kernel.org, gustavo...@collabora.com, paw...@collabora.com, spb...@gmail.com, tales.a...@gmail.com, work...@vger.kernel.org, kern...@lists.linux.dev, sk...@linuxfoundation.org, kuni...@googlegroups.com, nfra...@collabora.com, davi...@google.com, co...@inria.fr, Julia....@inria.fr, laur...@collabora.com, ricardo...@collabora.com, ker...@collabora.com, torv...@linuxfoundation.org, gre...@linuxfoundation.org
This patch introduces a `.gitlab-ci` file along with a `ci/` folder,
defininga 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.

[ci: add prerequisites to run check-patch on MRs]
Co-developed-by: Tales Aparecida <tales.a...@redhat.com>
Signed-off-by: Tales Aparecida <tales.a...@redhat.com>
Signed-off-by: Helen Koike <helen...@collabora.com>

---

Hey all,

You can check the validation of this patchset on:
https://gitlab.collabora.com/koike/linux/-/pipelines/87035

I would appreciate your feedback on this work, what do you think?

If you would rate from 0 to 5, where:

[ ] 0. I don't think this is useful at all, and I doubt it will ever be. It doesn't seem worthwhile.
[ ] 1. I don't find it useful in its current form.
[ ] 2. It might be useful to others, but not for me.
[ ] 3. It has potential, but it's not yet something I can incorporate into my workflow.
[ ] 4. This is useful, but it needs some adjustments before I can include it in my workflow.
[ ] 5. This is really useful! I'm eager to start using it right away. Why didn't you send this earlier? :)

Which rating would you select?

---
.gitlab-ci.yml | 2 +
MAINTAINERS | 8 ++
ci/gitlab-ci/bootstrap-gitlab-runner.sh | 55 +++++++++
ci/gitlab-ci/ci-scripts/build-docs.sh | 35 ++++++
ci/gitlab-ci/ci-scripts/build-kernel.sh | 35 ++++++
ci/gitlab-ci/ci-scripts/ici-functions.sh | 104 ++++++++++++++++++
ci/gitlab-ci/ci-scripts/install-smatch.sh | 13 +++
.../ci-scripts/parse_commit_message.sh | 27 +++++
ci/gitlab-ci/ci-scripts/run-checkpatch.sh | 20 ++++
ci/gitlab-ci/ci-scripts/run-smatch.sh | 45 ++++++++
ci/gitlab-ci/docker-compose.yaml | 18 +++
ci/gitlab-ci/linux.code-workspace | 11 ++
ci/gitlab-ci/yml/build.yml | 43 ++++++++
ci/gitlab-ci/yml/cache.yml | 26 +++++
ci/gitlab-ci/yml/container.yml | 36 ++++++
ci/gitlab-ci/yml/gitlab-ci.yml | 71 ++++++++++++
ci/gitlab-ci/yml/kernel-combinations.yml | 18 +++
ci/gitlab-ci/yml/scenarios.yml | 12 ++
ci/gitlab-ci/yml/scenarios/file-systems.yml | 21 ++++
ci/gitlab-ci/yml/scenarios/media.yml | 21 ++++
ci/gitlab-ci/yml/scenarios/network.yml | 21 ++++
ci/gitlab-ci/yml/static-checks.yml | 21 ++++
22 files changed, 663 insertions(+)
create mode 100644 .gitlab-ci.yml
create mode 100755 ci/gitlab-ci/bootstrap-gitlab-runner.sh
create mode 100755 ci/gitlab-ci/ci-scripts/build-docs.sh
create mode 100755 ci/gitlab-ci/ci-scripts/build-kernel.sh
create mode 100644 ci/gitlab-ci/ci-scripts/ici-functions.sh
create mode 100755 ci/gitlab-ci/ci-scripts/install-smatch.sh
create mode 100755 ci/gitlab-ci/ci-scripts/parse_commit_message.sh
create mode 100755 ci/gitlab-ci/ci-scripts/run-checkpatch.sh
create mode 100755 ci/gitlab-ci/ci-scripts/run-smatch.sh
create mode 100644 ci/gitlab-ci/docker-compose.yaml
create mode 100644 ci/gitlab-ci/linux.code-workspace
create mode 100644 ci/gitlab-ci/yml/build.yml
create mode 100644 ci/gitlab-ci/yml/cache.yml
create mode 100644 ci/gitlab-ci/yml/container.yml
create mode 100644 ci/gitlab-ci/yml/gitlab-ci.yml
create mode 100644 ci/gitlab-ci/yml/kernel-combinations.yml
create mode 100644 ci/gitlab-ci/yml/scenarios.yml
create mode 100644 ci/gitlab-ci/yml/scenarios/file-systems.yml
create mode 100644 ci/gitlab-ci/yml/scenarios/media.yml
create mode 100644 ci/gitlab-ci/yml/scenarios/network.yml
create mode 100644 ci/gitlab-ci/yml/static-checks.yml

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
new file mode 100644
index 0000000000000..fac523bb86866
--- /dev/null
+++ b/.gitlab-ci.yml
@@ -0,0 +1,2 @@
+include:
+ - ci/gitlab-ci/yml/gitlab-ci.yml
diff --git a/MAINTAINERS b/MAINTAINERS
index 716b2e22598c8..aa0f65791c2ee 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4998,6 +4998,14 @@ T: git git://linuxtv.org/media_tree.git
F: Documentation/devicetree/bindings/media/i2c/chrontel,ch7322.yaml
F: drivers/media/cec/i2c/ch7322.c

+CI AUTOMATED TESTING
+M: Helen Koike <helen...@collabora.com>
+L: linux-...@vger.kernel.org
+S: Maintained
+T: git https://gitlab.collabora.com/koike/linux.git
+F: .gitlab-ci.yml
+F: ci/
+
CIRRUS LOGIC AUDIO CODEC DRIVERS
M: James Schulman <james.s...@cirrus.com>
M: David Rhodes <david....@cirrus.com>
diff --git a/ci/gitlab-ci/bootstrap-gitlab-runner.sh b/ci/gitlab-ci/bootstrap-gitlab-runner.sh
new file mode 100755
index 0000000000000..73238960d0880
--- /dev/null
+++ b/ci/gitlab-ci/bootstrap-gitlab-runner.sh
@@ -0,0 +1,55 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2024 Collabora, Helen Koike <helen...@collabora.com>
+
+set -eo pipefail
+
+# Define variables
+CONFIG_VOLUME="/srv/gitlab-runner/config" # Path to your GitLab Runner config
+
+# Check if RUNNER_REGISTRATION_TOKEN is set
+if [ -z "${RUNNER_REGISTRATION_TOKEN}" ]; then
+ echo "Error: RUNNER_REGISTRATION_TOKEN is not set."
+ echo "Please set the RUNNER_REGISTRATION_TOKEN environment variable and try again."
+ exit 1
+fi
+
+# Check if GITLAB_URL is set
+if [ -z "${GITLAB_URL}" ]; then
+ GITLAB_URL="https://gitlab.com/"
+ echo "Info: GITLAB_URL is not set. Using the default $GITLAB_URL"
+ echo "Please set the RUNNER_REGISTRATION_TOKEN environment variable and try again."
+fi
+
+# Check if docker-compose is installed
+if ! command -v docker-compose &> /dev/null
+then
+ echo "docker-compose could not be found. Please install it first."
+ exit 1
+fi
+
+# Start the GitLab Runner using Docker Compose
+echo "Starting GitLab Runner..."
+docker-compose up -d
+
+# Wait for a few seconds to ensure the service is up
+sleep 5
+
+# Register the GitLab Runner
+echo "Registering GitLab Runner..."
+docker run --rm -v ${CONFIG_VOLUME}:/etc/gitlab-runner gitlab/gitlab-runner register \
+ --non-interactive \
+ --url ${GITLAB_URL} \
+ --token ${RUNNER_REGISTRATION_TOKEN} \
+ --executor docker \
+ --docker-image "alpine:latest" \
+ --description "Docker Runner" \
+ --docker-privileged
+
+echo ""
+echo "INFO: To configure the number of concurrent jobs, edit the value of"
+echo "INFO: concurrent in ${CONFIG_VOLUME}/config.toml, than restart the GitLab"
+echo "INFO: Runner using docker-compose restart"
+echo ""
+echo "GitLab Runner setup complete."
diff --git a/ci/gitlab-ci/ci-scripts/build-docs.sh b/ci/gitlab-ci/ci-scripts/build-docs.sh
new file mode 100755
index 0000000000000..2053cb8794acf
--- /dev/null
+++ b/ci/gitlab-ci/ci-scripts/build-docs.sh
@@ -0,0 +1,35 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2024 Collabora, Helen Koike <helen...@collabora.com>
+
+set -exo pipefail
+
+source ci/gitlab-ci/ci-scripts/ici-functions.sh
+
+ici_get_patch_series_size
+
+# Get the list of modified files in the last $ICI_PATCH_SERIES_SIZE commits
+MODIFIED_DOC_FILES=$(git diff HEAD~$ICI_PATCH_SERIES_SIZE --name-only -- Documentation/)
+
+make -j$(nproc) "$ICI_DOC_TYPE" 2>&1 | tee output.txt
+
+mkdir -p "${CI_PROJECT_DIR}/artifacts"
+mv Documentation/output "${CI_PROJECT_DIR}/artifacts/Documentation-output"
+
+# Check if any of the MODIFIED_DOC_FILES generated a warning
+# NOTE: the alternative solution was to touch the modified files and run make
+# again, but too much warnings still appears
+for file in $MODIFIED_DOC_FILES; do
+ if grep -qi "warning" output.txt && grep -q "$file" output.txt; then
+ echo "Warning found in $file"
+ exit 101
+ fi
+done
+
+if [ -n "$ICI_UNABLE_TO_DETECT_PATCH_SERIES_SIZE" ]; then
+ # If the patch series size was not detected, exit with a warning
+ echo -n "The patch series size was not detected, we probably didn't check the"
+ echo " whole series. Exiting with a warning."
+ exit 101
+fi
diff --git a/ci/gitlab-ci/ci-scripts/build-kernel.sh b/ci/gitlab-ci/ci-scripts/build-kernel.sh
new file mode 100755
index 0000000000000..361826368a573
--- /dev/null
+++ b/ci/gitlab-ci/ci-scripts/build-kernel.sh
@@ -0,0 +1,35 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2024 Collabora, Helen Koike <helen...@collabora.com>
+
+set -exo pipefail
+
+source ci/gitlab-ci/ci-scripts/ici-functions.sh
+
+ici_prepare_build
+
+pushd build
+
+# compile the entire kernel
+make CF=-D__CHECK_ENDIAN__ -C "$ICI_KERNEL_DIR" O=$(pwd) -j$(nproc) 2>&1 | tee output.txt
+
+export INSTALL_PATH="${CI_PROJECT_DIR}/artifacts/"
+INSTALL_PATH+="kernel-install-${KCI_KERNEL_ARCH}-${KCI_DEFCONFIG}_config"
+mkdir -p "$INSTALL_PATH"
+
+# install the kernel image to artifacts/kernel-install
+make -C "$ICI_KERNEL_DIR" O=$(pwd) install INSTALL_PATH="$INSTALL_PATH"
+
+# install kernel modules to artifacts/kernel-install
+make -C "$ICI_KERNEL_DIR" O=$(pwd) modules_install INSTALL_MOD_PATH="$INSTALL_PATH"
+
+# export config as artifact
+cp .config "${CI_PROJECT_DIR}/artifacts/${KCI_KERNEL_ARCH}-${KCI_DEFCONFIG}_config"
+
+# if the compilation has warnings, exit with the warning code
+if grep -iq "warning" output.txt; then
+ exit 101
+fi
+
+popd
diff --git a/ci/gitlab-ci/ci-scripts/ici-functions.sh b/ci/gitlab-ci/ci-scripts/ici-functions.sh
new file mode 100644
index 0000000000000..df133b4d00103
--- /dev/null
+++ b/ci/gitlab-ci/ci-scripts/ici-functions.sh
@@ -0,0 +1,104 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2024 Collabora, Helen Koike <helen...@collabora.com>
+
+set -exo pipefail
+
+# internal CI bash functions
+
+# convention:
+# KCI_<VARIABLE_NAME> for variables defined by the user (outside of this script)
+# ICI_<VARIABLE_NAME> for variables defined internally for usage between scripts
+# CI_<VARIABLE_NAME> for variables defined by GitLab CI
+
+
+ici_prepare_build() {
+ BUILD_DIR="${1:-build}"
+
+ echo ""
+ echo "Architecture: $KCI_KERNEL_ARCH"
+ echo "Defconfig: $KCI_DEFCONFIG"
+ echo ""
+
+ # Get the current directory if KCI_KERNEL_DIR is not set
+ ICI_KERNEL_DIR="${KCI_KERNEL_DIR:-$(pwd)}"
+
+ cd "$ICI_KERNEL_DIR" || { echo "Kernel directory not found"; exit 1; }
+
+ # Clean up stale rebases that GitLab might not have removed when reusing a checkout dir
+ rm -rf .git/rebase-apply
+
+ if [[ "$KCI_KERNEL_ARCH" = "arm64" ]]; then
+ GCC_ARCH="aarch64-linux-gnu"
+ elif [[ "$KCI_KERNEL_ARCH" = "arm" ]]; then
+ GCC_ARCH="arm-linux-gnueabihf"
+ else
+ GCC_ARCH="x86_64-linux-gnu"
+ fi
+
+ # do not set ARCH and CROSS_COMPILE if KCI_KERNEL_ARCH is not set, useful for local run
+ if [ -n "$KCI_KERNEL_ARCH" ]; then
+ export ARCH=${KCI_KERNEL_ARCH}
+ export CROSS_COMPILE="${GCC_ARCH}-"
+ fi
+
+ mkdir -p "$BUILD_DIR"
+
+ pushd "$BUILD_DIR" || { echo "Failed to create $BUILD_DIR directory"; exit 1; }
+
+ # generate defconfig
+ make -C "$ICI_KERNEL_DIR" O=$(pwd) $(basename ${KCI_DEFCONFIG-"defconfig"})
+
+ # add extra configs from variable KCI_KCONFIGS_{ENABLE,DISABLE,MODULE}
+ for opt in $KCI_KCONFIGS_ENABLE; do
+ ../scripts/config --file .config --enable CONFIG_$opt
+ done
+ for opt in $KCI_KCONFIGS_DISABLE; do
+ ../scripts/config --file .config --disable CONFIG_$opt
+ done
+ for opt in $KCI_KCONFIGS_MODULE; do
+ ../scripts/config --file .config --module CONFIG_$opt
+ done
+
+ if [ -n "$KCI_KCONFIGS_DISABLE" ] || [ -n "$KCI_KCONFIGS_ENABLE" ] ||
+ [ -n "$KCI_KCONFIGS_MODULE" ]; then
+ # execude olddefconfig only if we changed the default config, otherwise,
+ # let it raise warnings if any
+ make -C "$ICI_KERNEL_DIR" O=$(pwd) olddefconfig
+ fi
+
+ popd
+}
+
+ici_get_patch_series_size()
+{
+ local CLONE_DEPTH
+ CLONE_DEPTH=$(git rev-list --count HEAD)
+ echo "The depth of the clone is $CLONE_DEPTH"
+
+ # If this is in the context of a merge request, calculate the patch series
+ # size comparing to the target branch
+ if [ -n "$CI_MERGE_REQUEST_IID" ]; then
+ git fetch origin "$CI_MERGE_REQUEST_TARGET_BRANCH_NAME" --depth $CLONE_DEPTH
+ BASE_COMMIT="origin/$CI_MERGE_REQUEST_TARGET_BRANCH_NAME"
+ ICI_PATCH_SERIES_SIZE=$(git rev-list --count ${BASE_COMMIT}.."$CI_COMMIT_SHA")
+
+ # if KCI_PATCH_SERIES_SIZE is set, use it
+ elif [ -n "$KCI_PATCH_SERIES_SIZE" ]; then
+ ICI_PATCH_SERIES_SIZE="$KCI_PATCH_SERIES_SIZE"
+ else
+ ICI_PATCH_SERIES_SIZE=1
+ echo "WARNING: unable to detect the patch series size, using the default value of 1."
+ # shellcheck disable=SC2034
+ ICI_UNABLE_TO_DETECT_PATCH_SERIES_SIZE=true
+ fi
+
+ # Check if the clone depth is smaller than or equal to KCI_PATCH_SERIES_SIZE,
+ # otherwise the checkpatch.pl hangs
+ if [ "$ICI_PATCH_SERIES_SIZE" -ge "$CLONE_DEPTH" ]; then
+ echo -n "ERROR: the depth of the clone is $CLONE_DEPTH, smaller than or equal to the patch"
+ echo " series size. Update your GitLab configuration to increase the size of the clone."
+ return 1
+ fi
+}
diff --git a/ci/gitlab-ci/ci-scripts/install-smatch.sh b/ci/gitlab-ci/ci-scripts/install-smatch.sh
new file mode 100755
index 0000000000000..cae16a0e90fa8
--- /dev/null
+++ b/ci/gitlab-ci/ci-scripts/install-smatch.sh
@@ -0,0 +1,13 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2024 Collabora, Helen Koike <helen...@collabora.com>
+
+set -exo pipefail
+
+pushd /
+git clone --depth 1 https://repo.or.cz/smatch.git
+pushd smatch
+make
+popd
+popd
diff --git a/ci/gitlab-ci/ci-scripts/parse_commit_message.sh b/ci/gitlab-ci/ci-scripts/parse_commit_message.sh
new file mode 100755
index 0000000000000..c9792c64ad51e
--- /dev/null
+++ b/ci/gitlab-ci/ci-scripts/parse_commit_message.sh
@@ -0,0 +1,27 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2024 Collabora, Helen Koike <helen...@collabora.com>
+
+set -exo pipefail
+
+# Get the last commit message
+commit_message=$(git log -1 --pretty=%B)
+
+pattern='(KCI_[A-Za-z_]+)=("[^"]*"|[^ ]+)'
+
+while read -r line; do
+ if [[ $line =~ $pattern ]]; then
+ variable_name="${BASH_REMATCH[1]}"
+ variable_value="${BASH_REMATCH[2]}"
+
+ # Remove quotes if present
+ variable_value="${variable_value%\"}"
+ variable_value="${variable_value#\"}"
+
+ # Export the variable
+ export "$variable_name=$variable_value"
+
+ echo "Exported $variable_name=$variable_value"
+ fi
+done <<< "$commit_message"
diff --git a/ci/gitlab-ci/ci-scripts/run-checkpatch.sh b/ci/gitlab-ci/ci-scripts/run-checkpatch.sh
new file mode 100755
index 0000000000000..98585ec18be2b
--- /dev/null
+++ b/ci/gitlab-ci/ci-scripts/run-checkpatch.sh
@@ -0,0 +1,20 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2024 Collabora, Helen Koike <helen...@collabora.com>
+
+set -exo pipefail
+
+source ci/gitlab-ci/ci-scripts/ici-functions.sh
+
+ici_get_patch_series_size
+
+# shellcheck disable=SC2086
+scripts/checkpatch.pl $KCI_CHECKPATCH_OPTIONS --git HEAD-"$ICI_PATCH_SERIES_SIZE"
+
+if [ -n "$ICI_UNABLE_TO_DETECT_PATCH_SERIES_SIZE" ]; then
+ # If the patch series size was not detected, exit with a warning
+ echo -n "The patch series size was not detected, we probably didn't check the whole series."
+ echo " Exiting with a warning."
+ exit 101
+fi
diff --git a/ci/gitlab-ci/ci-scripts/run-smatch.sh b/ci/gitlab-ci/ci-scripts/run-smatch.sh
new file mode 100755
index 0000000000000..ec054df9ef179
--- /dev/null
+++ b/ci/gitlab-ci/ci-scripts/run-smatch.sh
@@ -0,0 +1,45 @@
+#!/bin/bash
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2024 Collabora, Helen Koike <helen...@collabora.com>
+
+set -exo pipefail
+
+source ci/gitlab-ci/ci-scripts/ici-functions.sh
+
+ls -l
+pwd
+
+# generate config file
+ici_prepare_build
+
+ici_get_patch_series_size
+
+cp build/.config .
+
+# Get a list of modified .c files in the last ICI_PATCH_SERIES_SIZE commits
+MODIFIED_C_FILES=$(git diff --name-only HEAD~$ICI_PATCH_SERIES_SIZE HEAD | grep '\.c$' || true)
+
+# Check if any .c files were modified
+if [ -z "$MODIFIED_C_FILES" ]; then
+ echo "No .c files were modified in the last $ICI_PATCH_SERIES_SIZE commits."
+else
+ echo "Running kchecker on modified .c files..."
+ mkdir -p "$CI_PROJECT_DIR"/artifacts
+fi
+
+# Run kchecker on each modified .c file
+for file in $MODIFIED_C_FILES; do
+ if [ -f "$file" ]; then
+ /smatch/smatch_scripts/kchecker "$file" | tee "$CI_PROJECT_DIR"/artifacts/smatch_warns.txt
+ else
+ echo "File not found: $file"
+ fi
+done
+
+if [ -n "$ICI_UNABLE_TO_DETECT_PATCH_SERIES_SIZE" ]; then
+ # If the patch series size was not detected, exit with a warning
+ echo -n "The patch series size was not detected, we probably didn't check the whole series."
+ echo " Exiting with a warning."
+ exit 101
+fi
diff --git a/ci/gitlab-ci/docker-compose.yaml b/ci/gitlab-ci/docker-compose.yaml
new file mode 100644
index 0000000000000..7edf8055ca375
--- /dev/null
+++ b/ci/gitlab-ci/docker-compose.yaml
@@ -0,0 +1,18 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2024 Collabora, Helen Koike <helen...@collabora.com>
+
+version: '3.8'
+
+services:
+ gitlab-runner:
+ image: gitlab/gitlab-runner:latest
+ container_name: gitlab-runner
+ restart: always
+ privileged: true
+ volumes:
+ - /srv/gitlab-runner/config:/etc/gitlab-runner
+ - /var/run/docker.sock:/var/run/docker.sock
+
+# To register the GitLab Runner, run the following command:
+# docker run --rm -it -v /srv/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register --url https://gitlab.com --token YOUR_REGISTRATION_TOKEN
diff --git a/ci/gitlab-ci/linux.code-workspace b/ci/gitlab-ci/linux.code-workspace
new file mode 100644
index 0000000000000..dd76698e38c2c
--- /dev/null
+++ b/ci/gitlab-ci/linux.code-workspace
@@ -0,0 +1,11 @@
+{
+ "folders": [
+ {
+ "path": "../../../.."
+ },
+ {
+ "path": "../../../../../mesa"
+ }
+ ],
+ "settings": {}
+}
\ No newline at end of file
diff --git a/ci/gitlab-ci/yml/build.yml b/ci/gitlab-ci/yml/build.yml
new file mode 100644
index 0000000000000..f81410c293f35
--- /dev/null
+++ b/ci/gitlab-ci/yml/build.yml
@@ -0,0 +1,43 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2024 Collabora, Helen Koike <helen...@collabora.com>
+
+.build:
+ extends: .use-debian/x86_64_build
+ stage: build
+
+build-kernel:
+ extends:
+ - .build
+ - .kernel-combinations
+ variables:
+ # ccache in gitlab-runner to speed up builds
+ CCACHE_BASEDIR: $CI_PROJECT_DIR
+ CCACHE_DIR: $CI_PROJECT_DIR/ccache
+ CCACHE_COMPILERCHECK: content
+ cache:
+ - key: ccache-$CI_JOB_NAME
+ paths:
+ - $CCACHE_DIR
+ before_script:
+ - export PATH="/usr/lib/ccache:$PATH"
+ - ccache --zero-stats || true
+ - ccache --show-stats || true
+ after_script:
+ - ccache --show-stats
+ script:
+ - ./ci/gitlab-ci/ci-scripts/build-kernel.sh
+
+build-docs:
+ extends:
+ - .build
+ parallel:
+ matrix:
+ - ICI_DOC_TYPE: "htmldocs"
+ # TODO: re-add pdfdocs once build errors are fixed
+ # - ICI_DOC_TYPE: "pdfdocs"
+ - ICI_DOC_TYPE: "latexdocs"
+ - ICI_DOC_TYPE: "epubdocs"
+ script:
+ - ./ci/gitlab-ci/ci-scripts/build-docs.sh
+ when: manual
\ No newline at end of file
diff --git a/ci/gitlab-ci/yml/cache.yml b/ci/gitlab-ci/yml/cache.yml
new file mode 100644
index 0000000000000..efe4fc69b11ca
--- /dev/null
+++ b/ci/gitlab-ci/yml/cache.yml
@@ -0,0 +1,26 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2024 Collabora, Helen Koike <helen...@collabora.com>
+
+# Smatch db is saved to a cached folder, so it can be used by other jobs and pipelines.
+# It is set to manual so it can be run when needed
+
+.use-cache-smatch-db:
+ cache:
+ # TODO: check if this cache shouldn't be per architecture
+ - key: smatch-db
+ paths:
+ - /smatch/smatch_data
+
+smatch-db-generate:
+ stage: cache
+ extends:
+ - .kernel-combinations
+ - .use-debian/x86_64_build
+ - .use-cache-smatch-db
+ script:
+ - source ci/gitlab-ci/ci-scripts/ici-functions.sh
+ - ici_prepare_build
+ - cp build/.config .
+ - /smatch/smatch_scripts/build_kernel_data.sh
+ when: manual
\ No newline at end of file
diff --git a/ci/gitlab-ci/yml/container.yml b/ci/gitlab-ci/yml/container.yml
new file mode 100644
index 0000000000000..eecca95caca0e
--- /dev/null
+++ b/ci/gitlab-ci/yml/container.yml
@@ -0,0 +1,36 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2024 Collabora, Helen Koike <helen...@collabora.com>
+
+.prep-debian/x86_64_build:
+ variables:
+ FDO_DISTRIBUTION_VERSION: bookworm-slim
+ FDO_DISTRIBUTION_TAG: "2024-02-28-ci-test-1"
+
+
+debian/x86_64_build:
+ extends:
+ - ".fdo.container-build@debian"
+ - ".prep-debian/x86_64_build"
+ variables:
+ FDO_DISTRIBUTION_PACKAGES: >
+ make bc flex bison pahole mount build-essential
+ libcairo-dev libdw-dev libjson-c-dev libkmod2
+ libkmod-dev libpciaccess-dev libproc2-dev libudev-dev
+ libunwind-dev python3-docutils bc python3-ply
+ libssl-dev ccache
+ gcc-aarch64-linux-gnu binutils-aarch64-linux-gnu
+ gcc-arm-linux-gnueabihf binutils-arm-linux-gnueabihf
+ perl git kmod python3-git python3-yaml python3-dulwich
+ sqlite3 libsqlite3-dev libdbd-sqlite3-perl libssl-dev libtry-tiny-perl
+ python3-sphinx imagemagick graphviz dvipng python3-venv fonts-noto-cjk
+ latexmk librsvg2-bin texlive-lang-chinese texlive-xetex
+ FDO_DISTRIBUTION_EXEC: ./ci/gitlab-ci/ci-scripts/install-smatch.sh
+ stage: container
+
+
+.use-debian/x86_64_build:
+ extends:
+ - ".fdo.distribution-image@debian"
+ - ".prep-debian/x86_64_build"
+ needs: [debian/x86_64_build]
\ No newline at end of file
diff --git a/ci/gitlab-ci/yml/gitlab-ci.yml b/ci/gitlab-ci/yml/gitlab-ci.yml
new file mode 100644
index 0000000000000..57b9c02904713
--- /dev/null
+++ b/ci/gitlab-ci/yml/gitlab-ci.yml
@@ -0,0 +1,71 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2024 Collabora, Helen Koike <helen...@collabora.com>
+
+workflow:
+ name: $PIPELINE_NAME
+ rules:
+ # when triggered as a multi-project pipeline for an MR
+ - if: $CI_PIPELINE_SOURCE == 'pipeline' && $PARENT_MERGE_REQUEST_IID != null && $PARENT_MERGE_REQUEST_IID != ""
+ variables:
+ PIPELINE_NAME: 'Downstream pipeline for $PARENT_PROJECT_PATH!$PARENT_MERGE_REQUEST_IID'
+ # when triggered as a multi-project pipeline
+ - if: $CI_PIPELINE_SOURCE == 'pipeline'
+ variables:
+ PIPELINE_NAME: 'Downstream pipeline for $PARENT_PROJECT_PATH'
+ # when triggered via a schedule
+ - if: $CI_PIPELINE_SOURCE == 'schedule'
+ variables:
+ PIPELINE_NAME: 'Scheduled pipeline for $ONLY_JOB_NAME'
+ # for merge requests
+ - if: $CI_MERGE_REQUEST_ID
+ # when triggered via the REST api
+ - if: $CI_PIPELINE_SOURCE == 'api'
+ # for the tip of the default branch
+ - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
+ # when triggered via a trigger token
+ - if: $CI_PIPELINE_SOURCE == 'trigger'
+ # when triggered from a button press in the web interface
+ - if: $CI_PIPELINE_SOURCE == 'web'
+ # for branch tips without open MRs, ignoring special branches
+ - if: $CI_PIPELINE_SOURCE == 'push' && $CI_OPEN_MERGE_REQUESTS == null
+ # when forced via '-o ci.variable="FORCE_CI=true"' during pushing
+ - if: $FORCE_CI == 'true'
+
+variables:
+ FDO_UPSTREAM_REPO: helen.fornazier/linux # The repo where to look for cached images
+ # ccache builds in gitlab-runner to speed up builds
+ SMATCH_DB_DIR: /smatch/smatch_data
+ # exit code of bash script on `script` will be the exit code of the job
+ FF_USE_NEW_BASH_EVAL_STRATEGY: "true"
+
+default:
+ artifacts:
+ paths:
+ - artifacts/
+ when: always
+
+include:
+ - remote: 'https://gitlab.freedesktop.org/freedesktop/ci-templates/-/raw/16bc29078de5e0a067ff84a1a199a3760d3b3811/templates/ci-fairy.yml'
+ - remote: 'https://gitlab.freedesktop.org/freedesktop/ci-templates/-/raw/16bc29078de5e0a067ff84a1a199a3760d3b3811/templates/debian.yml'
+
+ - ci/gitlab-ci/yml/kernel-combinations.yml
+ - ci/gitlab-ci/yml/container.yml
+ - ci/gitlab-ci/yml/cache.yml
+ - ci/gitlab-ci/yml/build.yml
+ - ci/gitlab-ci/yml/static-checks.yml
+ - ci/gitlab-ci/yml/scenarios.yml
+
+before_script:
+ - source ci/gitlab-ci/ci-scripts/parse_commit_message.sh
+
+.use-debian/x86_64_build:
+ allow_failure:
+ # Code to exit with a warning
+ exit_codes: 101
+
+stages:
+ - container
+ - static-checks
+ - build
+ - cache
\ No newline at end of file
diff --git a/ci/gitlab-ci/yml/kernel-combinations.yml b/ci/gitlab-ci/yml/kernel-combinations.yml
new file mode 100644
index 0000000000000..87f08579ffd62
--- /dev/null
+++ b/ci/gitlab-ci/yml/kernel-combinations.yml
@@ -0,0 +1,18 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2024 Collabora, Helen Koike <helen...@collabora.com>
+
+.kernel-combinations:
+ parallel:
+ matrix:
+ - KCI_KERNEL_ARCH: "x86_64"
+ KCI_DEFCONFIG: "x86_64_defconfig"
+ KCI_KCONFIGS_ENABLE: "PROVE_LOCKING DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT CONFIG_DEBUG_SECTION_MISMATCH"
+
+ - KCI_KERNEL_ARCH: "arm64"
+ KCI_DEFCONFIG: "defconfig"
+ KCI_KCONFIGS_ENABLE: "PROVE_LOCKING DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT CONFIG_DEBUG_SECTION_MISMATCH"
+
+ - KCI_KERNEL_ARCH: "arm"
+ KCI_DEFCONFIG: "multi_v7_defconfig"
+ KCI_KCONFIGS_ENABLE: "PROVE_LOCKING DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT CONFIG_DEBUG_SECTION_MISMATCH"
\ No newline at end of file
diff --git a/ci/gitlab-ci/yml/scenarios.yml b/ci/gitlab-ci/yml/scenarios.yml
new file mode 100644
index 0000000000000..11598c3b6f2a9
--- /dev/null
+++ b/ci/gitlab-ci/yml/scenarios.yml
@@ -0,0 +1,12 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2024 Collabora, Helen Koike <helen...@collabora.com>
+
+# Extend the CI by including a test scenario here. The scenario will be
+# activated if KCI_SCENARIO is set to the scenario name. KCI_SCENARIO can be
+# defined in the gitlab-ci.yml file, or through GitLab UI.
+
+include:
+ - local: 'ci/gitlab-ci/yml/scenarios/$KCI_SCENARIO.yml'
+ rules:
+ - if: '$KCI_SCENARIO'
\ No newline at end of file
diff --git a/ci/gitlab-ci/yml/scenarios/file-systems.yml b/ci/gitlab-ci/yml/scenarios/file-systems.yml
new file mode 100644
index 0000000000000..66456600a9dd3
--- /dev/null
+++ b/ci/gitlab-ci/yml/scenarios/file-systems.yml
@@ -0,0 +1,21 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2024 Collabora, Helen Koike <helen...@collabora.com>
+
+# Write here specific configurations and extensions for the given scenario
+
+# Example - overwrite kernel combinations in the pipeline
+# .kernel-combinations:
+# parallel:
+# matrix:
+# - KCI_KERNEL_ARCH: "x86_64"
+# KCI_DEFCONFIG: "path/to/my/config/file_config"
+# KCI_ENABLE_KCONFIGS: "CONFIG1 CONFIG2 CONFIG3 ..."
+#
+# - KCI_KERNEL_ARCH: "arm64"
+# KCI_DEFCONFIG: "path/to/my/config/file_config"
+# KCI_ENABLE_KCONFIGS: "CONFIG1 CONFIG2 CONFIG3 ..."
+#
+# - KCI_KERNEL_ARCH: "arm"
+# KCI_DEFCONFIG: "path/to/my/config/file_config"
+# KCI_ENABLE_KCONFIGS: "CONFIG1 CONFIG2 CONFIG3 ..."
\ No newline at end of file
diff --git a/ci/gitlab-ci/yml/scenarios/media.yml b/ci/gitlab-ci/yml/scenarios/media.yml
new file mode 100644
index 0000000000000..66456600a9dd3
--- /dev/null
+++ b/ci/gitlab-ci/yml/scenarios/media.yml
@@ -0,0 +1,21 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2024 Collabora, Helen Koike <helen...@collabora.com>
+
+# Write here specific configurations and extensions for the given scenario
+
+# Example - overwrite kernel combinations in the pipeline
+# .kernel-combinations:
+# parallel:
+# matrix:
+# - KCI_KERNEL_ARCH: "x86_64"
+# KCI_DEFCONFIG: "path/to/my/config/file_config"
+# KCI_ENABLE_KCONFIGS: "CONFIG1 CONFIG2 CONFIG3 ..."
+#
+# - KCI_KERNEL_ARCH: "arm64"
+# KCI_DEFCONFIG: "path/to/my/config/file_config"
+# KCI_ENABLE_KCONFIGS: "CONFIG1 CONFIG2 CONFIG3 ..."
+#
+# - KCI_KERNEL_ARCH: "arm"
+# KCI_DEFCONFIG: "path/to/my/config/file_config"
+# KCI_ENABLE_KCONFIGS: "CONFIG1 CONFIG2 CONFIG3 ..."
\ No newline at end of file
diff --git a/ci/gitlab-ci/yml/scenarios/network.yml b/ci/gitlab-ci/yml/scenarios/network.yml
new file mode 100644
index 0000000000000..66456600a9dd3
--- /dev/null
+++ b/ci/gitlab-ci/yml/scenarios/network.yml
@@ -0,0 +1,21 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2024 Collabora, Helen Koike <helen...@collabora.com>
+
+# Write here specific configurations and extensions for the given scenario
+
+# Example - overwrite kernel combinations in the pipeline
+# .kernel-combinations:
+# parallel:
+# matrix:
+# - KCI_KERNEL_ARCH: "x86_64"
+# KCI_DEFCONFIG: "path/to/my/config/file_config"
+# KCI_ENABLE_KCONFIGS: "CONFIG1 CONFIG2 CONFIG3 ..."
+#
+# - KCI_KERNEL_ARCH: "arm64"
+# KCI_DEFCONFIG: "path/to/my/config/file_config"
+# KCI_ENABLE_KCONFIGS: "CONFIG1 CONFIG2 CONFIG3 ..."
+#
+# - KCI_KERNEL_ARCH: "arm"
+# KCI_DEFCONFIG: "path/to/my/config/file_config"
+# KCI_ENABLE_KCONFIGS: "CONFIG1 CONFIG2 CONFIG3 ..."
\ No newline at end of file
diff --git a/ci/gitlab-ci/yml/static-checks.yml b/ci/gitlab-ci/yml/static-checks.yml
new file mode 100644
index 0000000000000..a99a1ea910f40
--- /dev/null
+++ b/ci/gitlab-ci/yml/static-checks.yml
@@ -0,0 +1,21 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+#
+# Copyright (C) 2024 Collabora, Helen Koike <helen...@collabora.com>
+
+.static-checks:
+ stage: static-checks
+ extends:
+ - .use-debian/x86_64_build
+
+checkpatch:
+ extends: .static-checks
+ script:
+ - ci/gitlab-ci/ci-scripts/run-checkpatch.sh
+
+smatch:
+ extends:
+ - .static-checks
+ - .kernel-combinations
+ - .use-cache-smatch-db
+ script:
+ - ci/gitlab-ci/ci-scripts/run-smatch.sh
\ No newline at end of file
--
2.40.1

Helen Koike

unread,
Feb 28, 2024, 5:55:55 PMFeb 28
to linux...@linuxtv.org, dave....@collabora.com, mri...@kernel.org, linux-...@vger.kernel.org, dri-...@lists.freedesktop.org, linux-k...@vger.kernel.org, gustavo...@collabora.com, paw...@collabora.com, spb...@gmail.com, tales.a...@gmail.com, work...@vger.kernel.org, kern...@lists.linux.dev, sk...@linuxfoundation.org, kuni...@googlegroups.com, nfra...@collabora.com, davi...@google.com, co...@inria.fr, Julia....@inria.fr, laur...@collabora.com, ricardo...@collabora.com, ker...@collabora.com, torv...@linuxfoundation.org, gre...@linuxfoundation.org
Add documentation of kci-gitlab.

Signed-off-by: Helen Koike <helen...@collabora.com>
---
Documentation/ci/gitlab-ci/gitlab-ci.rst | 404 +++++++++++++++++++++++
Documentation/index.rst | 7 +
MAINTAINERS | 1 +
3 files changed, 412 insertions(+)
create mode 100644 Documentation/ci/gitlab-ci/gitlab-ci.rst

diff --git a/Documentation/ci/gitlab-ci/gitlab-ci.rst b/Documentation/ci/gitlab-ci/gitlab-ci.rst
new file mode 100644
index 0000000000000..4f7ef03cca95c
--- /dev/null
+++ b/Documentation/ci/gitlab-ci/gitlab-ci.rst
@@ -0,0 +1,404 @@
+.. SPDX-License-Identifier: GPL-2.0+
+
+=========================================
+Automated Testing with GitLab CI/CD
+=========================================
+
+This documentation outlines the GitLab CI/CD workflow for the Linux Kernel. The
+workflow is designed to simplify testing for developers, allowing tests to be
+run on any branch at any time, without the need for specific infrastructure.
+Tests are automatically triggered on each `git push`, with results displayed in
+the GitLab UI.
+
+.. image:: images/the-pipeline.png
+ :alt: GitLab-CI pipeline for kernel testing
+ :align: center
+
+Customizations and extensions of the pipeline are possible through the
+scenarios. Scenarios can override existing jobs, change configurations, or
+define new jobs and stages. See :ref:`extending-the-ci` section.
+
+.. note:: If you are unfamiliar with GitLab CI/CD basic concepts, please check
+ the `official documentation <https://docs.gitlab.com/ee/ci/>`_.
+
+.. only:: subproject and html
+
+ Indices
+ =======
+
+ * :ref:`genindex`
+
+Setup
+-----
+
+The GitLab CI pipeline is configured for **"out-of-the-box"** use. Pushing code to a
+GitLab repository automatically triggers the pipeline.
+
+ .. code-block:: bash
+
+ # Download the Linux kernel source code
+ git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
+ # Create a repository on GitLab and add it as a remote
+ git remote add gitlab https://gitlab.yourinstance.com/your-username/your-repo.git
+ # Push the code to GitLab
+ git push gitlab
+
+.. image:: images/pipelines-on-push.png
+ :alt: Pipeline triggered on push
+ :align: center
+
+Troubleshooting
+---------------
+
+If the pipeline doesn't trigger automatically, check the following:
+
+1. **Enable CI/CD in Project Settings:**
+
+ - Go to `Settings > General > Visibility, project features, permissions`.
+ - Under `Repository`, ensure the `CI/CD` toggle is enabled.
+
+2. **Enable Container Registry:**
+
+ - Still in `Settings`, find the `Container Registry` section.
+ - Enable the `Container Registry` toggle.
+
+3. **CI Minutes and Resources:**
+
+ - If you've exhausted CI minutes or other resources on the Free Tier,
+ consider setting up a local GitLab runner (see below).
+
+Setting Up a Local GitLab Runner
+--------------------------------
+
+You can use your own machine as a runner, instead of the shared runners provided
+by your GitLab instance.
+
+1. **Generate a GitLab Runner Token:**
+
+ - Navigate to `Settings > CI/CD > Runners`.
+ - Expand the `Runners` section and click on "New project runner".
+ - Choose "Run untagged jobs" and click "Create runner".
+ - Copy the provided token.
+
+.. image:: images/new-project-runner.png
+ :alt: New project runner button
+ :align: center
+
+2. **Launch the Runner:**
+
+ - Ensure Docker is installed and your user is added to the Docker group:
+
+ .. code-block:: bash
+
+ sudo usermod -aG docker <your-user>
+
+ - Log in again to apply the changes.
+ - Set up the runner:
+
+ .. code-block:: bash
+
+ export GITLAB_RUNNER_TOKEN=<your_token>
+ export GITLAB_URL=https://gitlab.yourinstance.com # Use this for instances other than gitlab.com
+ cd ci/gitlab-ci
+ ./bootstrap-gitlab-runner.sh
+
+
+Current Pipeline Jobs
+---------------------
+
+stage: container
+^^^^^^^^^^^^^^^^
+
+**job: debian/x86_64_build**
+
+This job prepares the container used by subsequent jobs. It starts from a base
+Debian image, installing necessary tools for building the kernel and running
+tests. The resulting image is pushed to the project registry and cached. If the
+image already exists in the registry, it won't be rebuilt.
+
+To force a rebuild, update the `FDO_DISTRIBUTION_TAG` variable in the
+`container.yml` file.
+
+stage: static-checks
+^^^^^^^^^^^^^^^^^^^^
+
+**job: checkpatch**
+
+Runs the `checkpatch.pl` script on the last `$ICI_PATCH_SERIES_SIZE` commits.
+This variable is determined by:
+
+- `ICI_PATCH_SERIES_SIZE=` The number of differing patches between target and
+ source branches for merge requests; Or
+- `ICI_PATCH_SERIES_SIZE=$KCI_PATCH_SERIES_SIZE` if `KCI_PATCH_SERIES_SIZE` is
+ set (see :ref:`how-to-set-variables` below).
+
+Defaults to 1 and raises a GitLab warning if unable to identify the number of
+commits.
+
+**job: smatch**
+
+Checks `.c` files in the last `$ICI_PATCH_SERIES_SIZE` commits. Spawns a
+"sub-job" for each architecture and configuration in `kernel-combinations.yml`.
+If a smatch database exists (see `job: smatch-db-generate` below), it reuses it.
+
+stage: build
+^^^^^^^^^^^^
+
+**job: build-kernel**
+
+Compiles the kernel. Spawns a "sub-job" for each architecture and configuration
+in `kernel-combinations.yml`. Uses `ccache` to speed up builds, with its
+database shared inside the runner or across runners if configured with S3.
+
+Raises a GitLab warning if "warning" is found in the build log.
+
+.. image:: images/job-matrix.png
+ :alt: Matrix of jobs under build-kernel
+ :align: center
+
+**job: build-docs**
+
+Builds documentation. Spawns a "sub-job" for each documentation type. Not run
+automatically; requires manual triggering.
+
+stage: cache
+^^^^^^^^^^^^
+
+**job: smatch-db-generate**
+
+Generates a smatch database for use by the `smatch` job. Not run automatically;
+requires manual triggering.
+
+.. _extending-the-ci:
+
+Extending the CI - Test Scenarios (KCI_SCENARIO)
+------------------------------------------------
+
+The pipeline offers flexibility and adaptability through the use of scenarios,
+enhancing the CI/CD process with broad customization options. Key capabilities
+include:
+
+- **Overriding Existing Jobs:** Tailor existing jobs to meet specific needs or
+ conditions.
+
+- **Changing Configurations:** Dynamically adapt job settings to suit various
+ environments or subsystem requirements.
+
+- **Defining New Jobs and Stages:** Introduce new jobs and stages for additional
+ tests, build processes, or deployment strategies.
+
+These features are particularly useful when a subsystem has distinct
+requirements. For instance, to enable testing different configurations for a
+specific architecture, running static checks with varied arguments, or
+installing specialized tools to conduct targeted tests.
+
+Writing a test scenario
+^^^^^^^^^^^^^^^^^^^^^^^
+
+The GitLab CI pipeline configuration allows for the inclusion of additional
+`.yml` files based on the `KCI_SCENARIO` variable. For example, setting
+`KCI_SCENARIO` to `media` includes `media.yml` from the `scenarios/` folder.
+
+To illustrate, building a specific architecture with a custom config can be
+achieved by overriding the `.kernel-combinations` hidden job in the
+`scenarios/my-scenario.yml` file:
+
+.. code-block:: yaml
+
+ .kernel-combinations:
+ parallel:
+ matrix:
+ - KCI_KERNEL_ARCH: "arm64"
+ KCI_DEFCONFIG: "my/custom/config1"
+ KCI_KCONFIGS_ENABLE: "CONFIG1 CONFIG2 CONFIG3"
+
+ - KCI_KERNEL_ARCH: "arm64"
+ KCI_DEFCONFIG: "my/custom/config2"
+ KCI_KCONFIGS_ENABLE: "CONFIG4 CONFIG5"
+
+This modifies builds and static checks for `arm64` with different
+configurations.
+
+To select this scenario, trigger the pipeline with KCI_SCENARIO=my-scenario. See
+:ref:`how-to-set-variables` below.
+
+Variables
+---------
+
+GitLab CI/CD supports various variables to modify pipeline behavior or for use
+in jobs.
+
+- **CI_ Prefix:** Standard GitLab CI/CD variables (see GitLab documentation).
+- **KCI_ Prefix:** Custom variables defined for kernel CI.
+- **ICI_ Prefix:** Internal variables used between scripts (not for external
+ use).
+
+.. _how-to-set-variables:
+
+How to Set Variables
+--------------------
+
+Variables can be set in several ways:
+
+- **Project Settings:** Under `CI/CD > Variables`.
+- **Pipeline UI:** When triggering a pipeline manually.
+- **Command Line:** When triggering a pipeline manually (see
+ :ref:`triggering-pipelines-from-command-line` below).
+- **YML Files:** Using the `variables` keyword.
+- **Commit Message:** For runtime variables only (see
+ :ref:`setting-variables-in-the-commit-message` below).
+
+.. image:: images/variables.png
+ :alt: Manual creation of pipeline
+ :align: center
+
+Variables Precedence
+--------------------
+
+- **Commit Message Variables:** Highest precedence if evaluated at runtime.
+- **Pipeline Variables:** Next in precedence.
+- **Project Variables:** Follow pipeline variables.
+- **YML File Variables:** Considered after the above levels.
+
+.. _setting-variables-in-the-commit-message:
+
+Setting Variables in the Commit Message
+---------------------------------------
+
+Runtime variables can be set in the commit message. Patterns like
+`KCI_VARIABLE=value` are extracted and exported to the job. To avoid including
+variables in the git history, add them after three dashes (`---`) in the commit
+message, as `git am` ignores text after this line.
+
+Example:
+
+.. code-block::
+
+ Title of my awesome commit
+
+ This is the commit message description of my awesome patch
+ ---
+ KCI_PATCH_SERIES_SIZE=4
+
+Description of Each Variable
+----------------------------
+
+**KCI_KERNEL_ARCH**
+ Defines the architecture to be used in the build-kernel and static checks
+ jobs. Usually set in the `.kernel-combinations` hidden job.
+
+**KCI_DEFCONFIG**
+ Defines the config file to be used in the build-kernel and static checks
+ jobs. Usually set in the `.kernel-combinations` hidden job.
+
+**KCI_KCONFIGS_{ENABLE,DISABLE,MODULE}**
+ Defines the extra configs to be enabled, disabled or set as a module, used
+ in the build-kernel and static checks jobs. Usually set in the
+ `.kernel-combinations` hidden job.
+
+**KCI_SCENARIO**
+ Used to select which extra scenario file to include in the pipeline. See
+ :ref:`extending-the-ci` section above. Usually set by the user at project or
+ pipeline level.
+
+**KCI_CHECKPATCH_OPTIONS**
+ Used in `checkpatch.pl "$KCI_CHECKPATCH_OPTIONS"` (see checkpatch
+ documentation). It is commonly used with the --ignore flag to suppress
+ specific warnings generated by checkpatch.pl. It can also be defined in the
+ commit message, since it is evaluated in run time.
+
+**KCI_PATCH_SERIES_SIZE**
+ Used to define the size of the patch series, see `job: checkpatch` section
+ above. It is evaluated in run time, and can be set in the commit message.
+
+.. _triggering-pipelines-from-command-line:
+
+Triggering Pipelines from Command Line
+--------------------------------------
+
+Pipelines can be triggered from the command line with custom variables using the
+`GitLab CLI tool <https://docs.gitlab.com/ee/editor_extensions/gitlab_cli>`_.
+
+Example:
+
+.. code-block:: bash
+
+ glab auth login
+ glab ci run -b gitlab-draft -R https://gitlab.collabora.com/koike/linux/ --variables-env KCI_PATCH_SERIES_SIZE:4
+
+
+Debugging and Replicating Jobs Locally
+--------------------------------------
+
+When a job fails in GitLab CI/CD, it's handy to replicate the issue in the
+same environment used by the GitLab CI/CD runner. This allows for interactive
+execution of each step and the use of debugging tools to pinpoint the failure's
+root cause.
+
+Rather than repeatedly modifying scripts and running the entire pipeline for
+debugging, you can download the specific Docker image used by the job and run it
+locally.
+
+To do this, first inspect the failed job in GitLab CI/CD. Look for a message
+indicating the Docker image used, typically in this format:
+
+ Pulling docker image registry.gitlab.collabora.com/koike/linux/debian/bookworm-slim:2024-02-6-ci-test-1
+
+You can then use this image to run the job locally. For example:
+
+.. code-block:: bash
+
+ IMAGE=registry.gitlab.collabora.com/koike/linux/debian/bookworm-slim:2024-02-6-ci-test-1
+ docker pull $IMAGE
+ docker run --rm -v `pwd`:/linux -w /linux $IMAGE bash
+
+
+Suggestions
+-----------
+
+Send Pipeline Links with Your Patch
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+When submitting patches or merge requests, it's highly beneficial to include
+links to the related GitLab CI pipelines. This practice enhances the review
+process in several ways:
+
+1. **Immediate Visibility:** Reviewers can immediately see the results of
+ automated tests, making it easier to assess the patch's impact.
+
+2. **Increased Confidence:** Successful pipeline runs increase confidence in the
+ changes, demonstrating that they pass existing tests.
+
+3. **Efficient Troubleshooting:** If there are issues, pipeline links allow both
+ authors and reviewers to quickly access logs and test results, facilitating
+ faster troubleshooting and iteration.
+
+4. **Transparency:** Providing pipeline links promotes transparency in the
+ development process, making it clear how changes have been verified.
+
+To include a pipeline link in your patch or merge request, simply copy the URL
+of the pipeline from your GitLab project's CI/CD pipeline page and paste it into
+your commit description after three dashes (`---`) or as a reply to your email
+patch.
+
+Always Green Pipeline
+^^^^^^^^^^^^^^^^^^^^^
+
+Maintaining an "always green" pipeline refers to the practice of ensuring that
+the main branch's pipeline is always in a passing state. This approach has
+several advantages:
+
+1. **Reliable Main Branch:** A green pipeline indicates a stable and reliable
+ main branch, which is crucial for continuous integration practices.
+
+2. **Immediate Feedback:** Developers receive immediate feedback on their
+ changes. If a merge causes the pipeline to fail, it's a clear signal that the
+ change introduced an issue.
+
+3. **Faster Iteration:** An always green pipeline facilitates faster development
+ and iteration, as developers can confidently build on top of the latest main
+ branch without worrying about hidden failures.
+
+4. **Culture of Responsibility:** It fosters a culture of responsibility, where
+ developers are encouraged to fix broken builds promptly and avoid merging
+ changes that could disrupt the pipeline.
\ No newline at end of file
diff --git a/Documentation/index.rst b/Documentation/index.rst
index 36e61783437c1..cc96548ea8ef0 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -101,6 +101,13 @@ Architecture-specific documentation

arch/index

+CI: Automated testing documentation
+===================================
+
+.. toctree::
+ :maxdepth: 2
+
+ ci/gitlab-ci/gitlab-ci

Other documentation
===================
diff --git a/MAINTAINERS b/MAINTAINERS
index aa0f65791c2ee..5627300397e23 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5004,6 +5004,7 @@ L: linux-...@vger.kernel.org
S: Maintained
T: git https://gitlab.collabora.com/koike/linux.git
F: .gitlab-ci.yml
+F: Documentation/ci/
F: ci/

CIRRUS LOGIC AUDIO CODEC DRIVERS
--
2.40.1

Helen Koike

unread,
Feb 28, 2024, 5:56:10 PMFeb 28
to linux...@linuxtv.org, dave....@collabora.com, mri...@kernel.org, linux-...@vger.kernel.org, dri-...@lists.freedesktop.org, linux-k...@vger.kernel.org, gustavo...@collabora.com, paw...@collabora.com, spb...@gmail.com, tales.a...@gmail.com, work...@vger.kernel.org, kern...@lists.linux.dev, sk...@linuxfoundation.org, kuni...@googlegroups.com, nfra...@collabora.com, davi...@google.com, co...@inria.fr, Julia....@inria.fr, laur...@collabora.com, ricardo...@collabora.com, ker...@collabora.com, torv...@linuxfoundation.org, gre...@linuxfoundation.org

Laurent Pinchart

unread,
Feb 28, 2024, 6:07:28 PMFeb 28
to Helen Koike, linux...@linuxtv.org, dave....@collabora.com, mri...@kernel.org, linux-...@vger.kernel.org, dri-...@lists.freedesktop.org, linux-k...@vger.kernel.org, gustavo...@collabora.com, paw...@collabora.com, spb...@gmail.com, tales.a...@gmail.com, work...@vger.kernel.org, kern...@lists.linux.dev, sk...@linuxfoundation.org, kuni...@googlegroups.com, nfra...@collabora.com, davi...@google.com, co...@inria.fr, Julia....@inria.fr, laur...@collabora.com, ricardo...@collabora.com, ker...@collabora.com, torv...@linuxfoundation.org, gre...@linuxfoundation.org
Hi Helen,

I appreciate the amount of work you've put into this, to improve testing
of the kernel as a whole. I'll need more time to answer, but please see
below for a quick comment already.
Could we communicate using free software please ? Furthermore, it's not
possible to create an account on that slack instance unless you have an
e-mail address affiliated with a small number of companies
(https://kernelci.slack.com/signup#/domain-signup). That's a big no-go
for me.
Regards,

Laurent Pinchart

Bird, Tim

unread,
Feb 28, 2024, 9:45:01 PMFeb 28
to Helen Koike, linux...@linuxtv.org, dave....@collabora.com, mri...@kernel.org, linux-...@vger.kernel.org, dri-...@lists.freedesktop.org, linux-k...@vger.kernel.org, gustavo...@collabora.com, paw...@collabora.com, spb...@gmail.com, tales.a...@gmail.com, work...@vger.kernel.org, kern...@lists.linux.dev, sk...@linuxfoundation.org, kuni...@googlegroups.com, nfra...@collabora.com, davi...@google.com, co...@inria.fr, Julia....@inria.fr, laur...@collabora.com, ricardo...@collabora.com, ker...@collabora.com, torv...@linuxfoundation.org, gre...@linuxfoundation.org
> -----Original Message-----
> From: Helen Koike <helen...@collabora.com>
>
....

> Hey all,
>
> You can check the validation of this patchset on:
> https://gitlab.collabora.com/koike/linux/-/pipelines/87035
>
> I would appreciate your feedback on this work, what do you think?
>
> If you would rate from 0 to 5, where:
>
> [ ] 0. I don't think this is useful at all, and I doubt it will ever be. It doesn't seem worthwhile.
> [ ] 1. I don't find it useful in its current form.
> [ ] 2. It might be useful to others, but not for me.
> [ ] 3. It has potential, but it's not yet something I can incorporate into my workflow.
> [ ] 4. This is useful, but it needs some adjustments before I can include it in my workflow.
> [ ] 5. This is really useful! I'm eager to start using it right away. Why didn't you send this earlier? :)
>
> Which rating would you select?

For me, this is a "5". I don't currently use gitlab, but I might install it just to test this out.

It looks like there are a large number of YAML files which define the integration between the
test scripts and gitlab. Also, there are a number of shell scripts to perform some of the setup
and tests. Do you have any idea how difficult it would be to use the shell scripts outside of
the CI system (e.g. manually)? That is, are there dependencies between the CI system
and the shell scripts?

I think the convention, of putting this kind of stuff under a "ci" directory, makes sense.
And it appears that the sub-dir structure allows for other CI systems to add their
own config and files also.

I have a few minor comments below.
I'm not sure, but do you need a popd here in this early exit path?
At the root? really? Could this be /usr/local/src or $HOME/src or something?
or is this inside a container and doesn't matter?
Do you have any real examples of scenario files? These all seem like
placeholders.
Looks very interesting!
-- Tim

Maxime Ripard

unread,
Feb 29, 2024, 3:43:29 AMFeb 29
to Laurent Pinchart, Helen Koike, linux...@linuxtv.org, dave....@collabora.com, linux-...@vger.kernel.org, dri-...@lists.freedesktop.org, linux-k...@vger.kernel.org, gustavo...@collabora.com, paw...@collabora.com, spb...@gmail.com, tales.a...@gmail.com, work...@vger.kernel.org, kern...@lists.linux.dev, sk...@linuxfoundation.org, kuni...@googlegroups.com, nfra...@collabora.com, davi...@google.com, co...@inria.fr, Julia....@inria.fr, laur...@collabora.com, ricardo...@collabora.com, ker...@collabora.com, torv...@linuxfoundation.org, gre...@linuxfoundation.org
On Thu, Feb 29, 2024 at 01:07:25AM +0200, Laurent Pinchart wrote:
> > Chat Discussions
> > ================
> >
> > For those interested in further discussions:
> >
> > **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.
>
> Could we communicate using free software please ? Furthermore, it's not
> possible to create an account on that slack instance unless you have an
> e-mail address affiliated with a small number of companies
> (https://kernelci.slack.com/signup#/domain-signup). That's a big no-go
> for me.

Yeah, and that list looks super restrictive and arbitrary. Like,
microsoft is there but kernel.org isn't?

I'm sure there's a reason, but we should at the very least open it to
everyone.

Maxime
signature.asc

Maxime Ripard

unread,
Feb 29, 2024, 4:02:19 AMFeb 29
to Helen Koike, linux...@linuxtv.org, dave....@collabora.com, linux-...@vger.kernel.org, dri-...@lists.freedesktop.org, linux-k...@vger.kernel.org, gustavo...@collabora.com, paw...@collabora.com, spb...@gmail.com, tales.a...@gmail.com, work...@vger.kernel.org, kern...@lists.linux.dev, sk...@linuxfoundation.org, kuni...@googlegroups.com, nfra...@collabora.com, davi...@google.com, co...@inria.fr, Julia....@inria.fr, laur...@collabora.com, ricardo...@collabora.com, ker...@collabora.com, torv...@linuxfoundation.org, gre...@linuxfoundation.org
Hi Helen,

Thanks for working on this
4.5 :)

One thing I'm wondering here is how we're going to cope with the
different requirements each user / framework has.

Like, Linus probably want to have a different set of CI before merging a
PR than (say) linux-next does, or stable, or before doing an actual
release.

Similarly, DRM probably has a different set of requirements than
drm-misc, drm-amd or nouveau.

I don't see how the current architecture could accomodate for that. I
know that Gitlab allows to store issues template in a separate repo,
maybe we could ask them to provide a feature where the actions would be
separate from the main repo? That way, any gitlab project could provide
its own set of tests, without conflicting with each others (and we could
still share them if we wanted to)

I know some of use had good relationship with Gitlab, so maybe it would
be worth asking?

Maxime
signature.asc

Nikolai Kondrashov

unread,
Feb 29, 2024, 4:23:27 AMFeb 29
to Maxime Ripard, Helen Koike, linux...@linuxtv.org, dave....@collabora.com, linux-...@vger.kernel.org, dri-...@lists.freedesktop.org, linux-k...@vger.kernel.org, gustavo...@collabora.com, paw...@collabora.com, tales.a...@gmail.com, work...@vger.kernel.org, kern...@lists.linux.dev, sk...@linuxfoundation.org, kuni...@googlegroups.com, nfra...@collabora.com, davi...@google.com, co...@inria.fr, Julia....@inria.fr, laur...@collabora.com, ricardo...@collabora.com, ker...@collabora.com, torv...@linuxfoundation.org, gre...@linuxfoundation.org
Hi everyone,
GitLab already supports getting the CI YAML from other repos. You can change
that in the repo settings.

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.

This way all the different subtrees can have completely different setup, but
some could still use Helen's work and employ the "scenarios" she implemented.

Nick

Nikolai Kondrashov

unread,
Feb 29, 2024, 4:26:55 AMFeb 29
to Laurent Pinchart, Helen Koike, linux...@linuxtv.org, dave....@collabora.com, mri...@kernel.org, linux-...@vger.kernel.org, dri-...@lists.freedesktop.org, linux-k...@vger.kernel.org, gustavo...@collabora.com, paw...@collabora.com, tales.a...@gmail.com, work...@vger.kernel.org, kern...@lists.linux.dev, sk...@linuxfoundation.org, kuni...@googlegroups.com, nfra...@collabora.com, davi...@google.com, co...@inria.fr, Julia....@inria.fr, laur...@collabora.com, ricardo...@collabora.com, ker...@collabora.com, torv...@linuxfoundation.org, gre...@linuxfoundation.org
On 2/29/24 01:07, Laurent Pinchart wrote:
> On Wed, Feb 28, 2024 at 07:55:24PM -0300, Helen Koike wrote:
>> **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.
>
> Could we communicate using free software please ? Furthermore, it's not
> possible to create an account on that slack instance unless you have an
> e-mail address affiliated with a small number of companies
> (https://kernelci.slack.com/signup#/domain-signup). That's a big no-go
> for me.

Yes, it's not ideal that we use closed-source software for communication, but
FWIW I'd be happy to invite you there. Perhaps if you try logging in e.g. with
a Google account, I'd be able to see and approve your attempt too.

Otherwise, our video meetings are generally open to everyone and run in Jitsi.

Nick

Laurent Pinchart

unread,
Feb 29, 2024, 4:34:03 AMFeb 29
to Nikolai Kondrashov, Helen Koike, linux...@linuxtv.org, dave....@collabora.com, mri...@kernel.org, linux-...@vger.kernel.org, dri-...@lists.freedesktop.org, linux-k...@vger.kernel.org, gustavo...@collabora.com, paw...@collabora.com, tales.a...@gmail.com, work...@vger.kernel.org, kern...@lists.linux.dev, sk...@linuxfoundation.org, kuni...@googlegroups.com, nfra...@collabora.com, davi...@google.com, co...@inria.fr, Julia....@inria.fr, laur...@collabora.com, ricardo...@collabora.com, ker...@collabora.com, torv...@linuxfoundation.org, gre...@linuxfoundation.org
I don't use Google accounts to authenticate to third-party services,
sorry. And in any case, that won't make slack free software.

> Otherwise, our video meetings are generally open to everyone and run in Jitsi.

--
Regards,

Laurent Pinchart

Sakari Ailus

unread,
Feb 29, 2024, 4:39:09 AMFeb 29
to Laurent Pinchart, Helen Koike, linux...@linuxtv.org, dave....@collabora.com, mri...@kernel.org, linux-...@vger.kernel.org, dri-...@lists.freedesktop.org, linux-k...@vger.kernel.org, paw...@collabora.com, tales.a...@gmail.com, work...@vger.kernel.org, kern...@lists.linux.dev, kuni...@googlegroups.com, nfra...@collabora.com, davi...@google.com, co...@inria.fr, Julia....@inria.fr, ker...@collabora.com, torv...@linuxfoundation.org, gre...@linuxfoundation.org
Hi Laurent, Helen,

On Thu, Feb 29, 2024 at 01:07:25AM +0200, Laurent Pinchart wrote:
> > **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.
>
> Could we communicate using free software please ? Furthermore, it's not
> possible to create an account on that slack instance unless you have an
> e-mail address affiliated with a small number of companies
> (https://kernelci.slack.com/signup#/domain-signup). That's a big no-go
> for me.

I agree. There is no shortage of good alternatives either: we have IRC,
Matrix and XMPP for instance. Just pick one of them.

--
Regards,

Sakari Ailus

Maxime Ripard

unread,
Feb 29, 2024, 4:57:03 AMFeb 29
to Nikolai Kondrashov, Helen Koike, linux...@linuxtv.org, dave....@collabora.com, linux-...@vger.kernel.org, dri-...@lists.freedesktop.org, linux-k...@vger.kernel.org, gustavo...@collabora.com, paw...@collabora.com, tales.a...@gmail.com, work...@vger.kernel.org, kern...@lists.linux.dev, sk...@linuxfoundation.org, kuni...@googlegroups.com, nfra...@collabora.com, davi...@google.com, co...@inria.fr, Julia....@inria.fr, laur...@collabora.com, ricardo...@collabora.com, ker...@collabora.com, torv...@linuxfoundation.org, gre...@linuxfoundation.org
Hi!

On Thu, Feb 29, 2024 at 11:23:22AM +0200, Nikolai Kondrashov wrote:
> Hi everyone,
>
> On 2/29/24 11:02, Maxime Ripard wrote:
> > On Wed, Feb 28, 2024 at 07:55:25PM -0300, Helen Koike wrote:
> > > Which rating would you select?
> >
> > 4.5 :)
> >
> > One thing I'm wondering here is how we're going to cope with the
> > different requirements each user / framework has.
> >
> > Like, Linus probably want to have a different set of CI before merging a
> > PR than (say) linux-next does, or stable, or before doing an actual
> > release.
> >
> > Similarly, DRM probably has a different set of requirements than
> > drm-misc, drm-amd or nouveau.
> >
> > I don't see how the current architecture could accomodate for that. I
> > know that Gitlab allows to store issues template in a separate repo,
> > maybe we could ask them to provide a feature where the actions would be
> > separate from the main repo? That way, any gitlab project could provide
> > its own set of tests, without conflicting with each others (and we could
> > still share them if we wanted to)
> >
> > I know some of use had good relationship with Gitlab, so maybe it would
> > be worth asking?
>
> GitLab already supports getting the CI YAML from other repos. You can change
> that in the repo settings.

I'm interested but couldn't find it in the doc, do you have a link to
the right section?

> 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.
>
> This way all the different subtrees can have completely different setup, but
> some could still use Helen's work and employ the "scenarios" she
> implemented.

I'm worried that this kind of setup will just create duplicated YAML
that will be developped in complete silos and will become difficult to
maintain. But that's definitely an opinion :)

Maxime
signature.asc

Laurent Pinchart

unread,
Feb 29, 2024, 5:05:07 AMFeb 29
to Maxime Ripard, Nikolai Kondrashov, Helen Koike, linux...@linuxtv.org, dave....@collabora.com, linux-...@vger.kernel.org, dri-...@lists.freedesktop.org, linux-k...@vger.kernel.org, gustavo...@collabora.com, paw...@collabora.com, tales.a...@gmail.com, work...@vger.kernel.org, kern...@lists.linux.dev, sk...@linuxfoundation.org, kuni...@googlegroups.com, nfra...@collabora.com, davi...@google.com, co...@inria.fr, Julia....@inria.fr, laur...@collabora.com, ricardo...@collabora.com, ker...@collabora.com, torv...@linuxfoundation.org, gre...@linuxfoundation.org
e.g. https://gitlab.freedesktop.org/camera/libcamera/-/settings/ci_cd

Expand "General pipelines", the setting is "CI/CD configuration file".
You can specify the path to a file in the local repository, or in a
separate repository. See
https://gitlab.freedesktop.org/help/ci/pipelines/settings#specify-a-custom-cicd-configuration-file
for the syntax.

> > 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.
> >
> > This way all the different subtrees can have completely different setup, but
> > some could still use Helen's work and employ the "scenarios" she
> > implemented.
>
> I'm worried that this kind of setup will just create duplicated YAML
> that will be developped in complete silos and will become difficult to
> maintain. But that's definitely an opinion :)

--
Regards,

Laurent Pinchart

Mark Brown

unread,
Feb 29, 2024, 6:09:50 AMFeb 29
to Sakari Ailus, Laurent Pinchart, Helen Koike, linux...@linuxtv.org, dave....@collabora.com, mri...@kernel.org, linux-...@vger.kernel.org, dri-...@lists.freedesktop.org, linux-k...@vger.kernel.org, paw...@collabora.com, tales.a...@gmail.com, work...@vger.kernel.org, kern...@lists.linux.dev, kuni...@googlegroups.com, nfra...@collabora.com, davi...@google.com, co...@inria.fr, Julia....@inria.fr, ker...@collabora.com, torv...@linuxfoundation.org, gre...@linuxfoundation.org
And indeed KernelCI does actually already have #kernelci on libera.chat.
signature.asc

Nikolai Kondrashov

unread,
Feb 29, 2024, 6:10:21 AMFeb 29
to Laurent Pinchart, Helen Koike, linux...@linuxtv.org, dave....@collabora.com, mri...@kernel.org, linux-...@vger.kernel.org, dri-...@lists.freedesktop.org, linux-k...@vger.kernel.org, gustavo...@collabora.com, paw...@collabora.com, tales.a...@gmail.com, work...@vger.kernel.org, kern...@lists.linux.dev, sk...@linuxfoundation.org, kuni...@googlegroups.com, nfra...@collabora.com, davi...@google.com, co...@inria.fr, Julia....@inria.fr, laur...@collabora.com, ricardo...@collabora.com, ker...@collabora.com, torv...@linuxfoundation.org, gre...@linuxfoundation.org
Of course. You're also welcome to join the #kernelci channel on libera.chat.

It's much quieter there, though.

Nick

Laurent Pinchart

unread,
Feb 29, 2024, 6:19:20 AMFeb 29
to Nikolai Kondrashov, Helen Koike, linux...@linuxtv.org, dave....@collabora.com, mri...@kernel.org, linux-...@vger.kernel.org, dri-...@lists.freedesktop.org, linux-k...@vger.kernel.org, gustavo...@collabora.com, paw...@collabora.com, tales.a...@gmail.com, work...@vger.kernel.org, kern...@lists.linux.dev, sk...@linuxfoundation.org, kuni...@googlegroups.com, nfra...@collabora.com, davi...@google.com, co...@inria.fr, Julia....@inria.fr, laur...@collabora.com, ricardo...@collabora.com, ker...@collabora.com, torv...@linuxfoundation.org, gre...@linuxfoundation.org
Isn't that a bit pointless if it's no the main IM channel ?

> It's much quieter there, though.

--
Regards,

Laurent Pinchart

Nikolai Kondrashov

unread,
Feb 29, 2024, 6:22:19 AMFeb 29
to Laurent Pinchart, Helen Koike, linux...@linuxtv.org, dave....@collabora.com, mri...@kernel.org, linux-...@vger.kernel.org, dri-...@lists.freedesktop.org, linux-k...@vger.kernel.org, gustavo...@collabora.com, paw...@collabora.com, tales.a...@gmail.com, work...@vger.kernel.org, kern...@lists.linux.dev, sk...@linuxfoundation.org, kuni...@googlegroups.com, nfra...@collabora.com, davi...@google.com, co...@inria.fr, Julia....@inria.fr, laur...@collabora.com, ricardo...@collabora.com, ker...@collabora.com, torv...@linuxfoundation.org, gre...@linuxfoundation.org
Yes, it's not ideal, but if more people come there, more discussions will
happen there too.

Nick


Mark Brown

unread,
Feb 29, 2024, 6:41:22 AMFeb 29
to Laurent Pinchart, Nikolai Kondrashov, Helen Koike, linux...@linuxtv.org, dave....@collabora.com, mri...@kernel.org, linux-...@vger.kernel.org, dri-...@lists.freedesktop.org, linux-k...@vger.kernel.org, gustavo...@collabora.com, paw...@collabora.com, tales.a...@gmail.com, work...@vger.kernel.org, kern...@lists.linux.dev, sk...@linuxfoundation.org, kuni...@googlegroups.com, nfra...@collabora.com, davi...@google.com, co...@inria.fr, Julia....@inria.fr, laur...@collabora.com, ricardo...@collabora.com, ker...@collabora.com, torv...@linuxfoundation.org, gre...@linuxfoundation.org
It *was* the original channel and still gets some usage (mostly started
by me admittedly since I've never joined slack for a bunch of reasons
that make it hassle), IIRC the Slack was started because there were some
interns who had trouble figuring out IRC and intermittent connectivity
but people seem to have migrated.
signature.asc

Guillaume Tucker

unread,
Feb 29, 2024, 6:53:45 AMFeb 29
to Mark Brown, Laurent Pinchart, Nikolai Kondrashov, Helen Koike, linux...@linuxtv.org, dave....@collabora.com, mri...@kernel.org, linux-...@vger.kernel.org, dri-...@lists.freedesktop.org, linux-k...@vger.kernel.org, gustavo...@collabora.com, paw...@collabora.com, tales.a...@gmail.com, work...@vger.kernel.org, kern...@lists.linux.dev, sk...@linuxfoundation.org, kuni...@googlegroups.com, nfra...@collabora.com, davi...@google.com, co...@inria.fr, Julia....@inria.fr, laur...@collabora.com, ricardo...@collabora.com, ker...@collabora.com, torv...@linuxfoundation.org, gre...@linuxfoundation.org
In fact it was initially created for the members of the Linux
Foundation project only, which is why registration is moderated
for emails that don't have a domain linked to a member (BTW not
any Google account will just work e.g. @gmail.com is moderated,
only @google.com for Google employees isn't).

And yes IRC is the "least common denominator" chat platform.
Maybe having a bridge between the main Slack channel and IRC
would help.

Guillaume

Laurent Pinchart

unread,
Feb 29, 2024, 7:20:41 AMFeb 29
to Guillaume Tucker, Mark Brown, Nikolai Kondrashov, Helen Koike, linux...@linuxtv.org, dave....@collabora.com, mri...@kernel.org, linux-...@vger.kernel.org, dri-...@lists.freedesktop.org, linux-k...@vger.kernel.org, gustavo...@collabora.com, paw...@collabora.com, tales.a...@gmail.com, work...@vger.kernel.org, kern...@lists.linux.dev, sk...@linuxfoundation.org, kuni...@googlegroups.com, nfra...@collabora.com, davi...@google.com, co...@inria.fr, Julia....@inria.fr, laur...@collabora.com, ricardo...@collabora.com, ker...@collabora.com, torv...@linuxfoundation.org, gre...@linuxfoundation.org
If the gitlab CI pipeline proposal wants to be considered for inclusion
in the kernel, I think it needs to switch to a free software solution
for its *main* communication channels.

--
Regards,

Laurent Pinchart

Guillaume Tucker

unread,
Feb 29, 2024, 7:20:46 AMFeb 29
to Helen Koike, linux...@linuxtv.org, dave....@collabora.com, mri...@kernel.org, linux-...@vger.kernel.org, dri-...@lists.freedesktop.org, linux-k...@vger.kernel.org, gustavo...@collabora.com, paw...@collabora.com, spb...@gmail.com, tales.a...@gmail.com, work...@vger.kernel.org, kern...@lists.linux.dev, sk...@linuxfoundation.org, kuni...@googlegroups.com, nfra...@collabora.com, davi...@google.com, co...@inria.fr, Julia....@inria.fr, laur...@collabora.com, ricardo...@collabora.com, ker...@collabora.com, torv...@linuxfoundation.org, gre...@linuxfoundation.org
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

Laurent Pinchart

unread,
Feb 29, 2024, 7:25:03 AMFeb 29
to Guillaume Tucker, Mark Brown, Nikolai Kondrashov, Helen Koike, linux...@linuxtv.org, dave....@collabora.com, mri...@kernel.org, linux-...@vger.kernel.org, dri-...@lists.freedesktop.org, linux-k...@vger.kernel.org, gustavo...@collabora.com, paw...@collabora.com, tales.a...@gmail.com, work...@vger.kernel.org, kern...@lists.linux.dev, sk...@linuxfoundation.org, kuni...@googlegroups.com, nfra...@collabora.com, davi...@google.com, co...@inria.fr, Julia....@inria.fr, laur...@collabora.com, ricardo...@collabora.com, ker...@collabora.com, torv...@linuxfoundation.org, gre...@linuxfoundation.org
And to clarify, I didn't meant the kernel CI project, but only the
gitlab CI pipeline for the Linux kernel project. I don't know how
tightly integrated the two projects are though.

--
Regards,

Laurent Pinchart

Nikolai Kondrashov

unread,
Feb 29, 2024, 9:12:48 AMFeb 29
to Laurent Pinchart, Guillaume Tucker, Mark Brown, Helen Koike, linux...@linuxtv.org, dave....@collabora.com, mri...@kernel.org, linux-...@vger.kernel.org, dri-...@lists.freedesktop.org, linux-k...@vger.kernel.org, gustavo...@collabora.com, paw...@collabora.com, tales.a...@gmail.com, work...@vger.kernel.org, kern...@lists.linux.dev, sk...@linuxfoundation.org, kuni...@googlegroups.com, nfra...@collabora.com, davi...@google.com, co...@inria.fr, Julia....@inria.fr, laur...@collabora.com, ricardo...@collabora.com, ker...@collabora.com, torv...@linuxfoundation.org, gre...@linuxfoundation.org
They're not tightly integrated so far. However, we're exploring the idea of
letting GitLab CI submit jobs to KernelCI and get results as a part of the
pipeline.

Helen already joined the #kernelci channel, and we will maintain a presence
there for the GitLab CI project.

Nick

Nikolai Kondrashov

unread,
Feb 29, 2024, 9:16:22 AMFeb 29
to Guillaume Tucker, Helen Koike, linux...@linuxtv.org, dave....@collabora.com, mri...@kernel.org, linux-...@vger.kernel.org, dri-...@lists.freedesktop.org, linux-k...@vger.kernel.org, gustavo...@collabora.com, paw...@collabora.com, tales.a...@gmail.com, work...@vger.kernel.org, kern...@lists.linux.dev, sk...@linuxfoundation.org, kuni...@googlegroups.com, nfra...@collabora.com, davi...@google.com, co...@inria.fr, Julia....@inria.fr, laur...@collabora.com, ricardo...@collabora.com, ker...@collabora.com, torv...@linuxfoundation.org, gre...@linuxfoundation.org
I would say this is an important part of KernelCI the project, considering its
aim to improve testing and CI in the kernel. It's not a part of KernelCI the
service as it is right now, although I would say it would be good to have
ability to submit KernelCI jobs from GitLab CI and pull results in the same
pipeline, as we discussed earlier.

Nick

Nicolas Dufresne

unread,
Feb 29, 2024, 11:15:56 AMFeb 29
to Bird, Tim, Helen Koike, linux...@linuxtv.org, dave....@collabora.com, mri...@kernel.org, linux-...@vger.kernel.org, dri-...@lists.freedesktop.org, linux-k...@vger.kernel.org, gustavo...@collabora.com, paw...@collabora.com, spb...@gmail.com, tales.a...@gmail.com, work...@vger.kernel.org, kern...@lists.linux.dev, sk...@linuxfoundation.org, kuni...@googlegroups.com, nfra...@collabora.com, davi...@google.com, co...@inria.fr, Julia....@inria.fr, laur...@collabora.com, ricardo...@collabora.com, ker...@collabora.com, torv...@linuxfoundation.org, gre...@linuxfoundation.org
Hi Tim,

just replying below to one of your comment which I happen to be involved in, but
I'll let others reply for the more specific comments.

Le jeudi 29 février 2024 à 02:44 +0000, Bird, Tim a écrit :
> > -----Original Message-----
> > From: Helen Koike <helen...@collabora.com>
> >
> ....
>
> > Hey all,
> >
> > You can check the validation of this patchset on:
> >         https://gitlab.collabora.com/koike/linux/-/pipelines/87035
> >
> > I would appreciate your feedback on this work, what do you think?
> >
> > If you would rate from 0 to 5, where:
> >
> > [ ] 0. I don't think this is useful at all, and I doubt it will ever be. It doesn't seem worthwhile.
> > [ ] 1. I don't find it useful in its current form.
> > [ ] 2. It might be useful to others, but not for me.
> > [ ] 3. It has potential, but it's not yet something I can incorporate into my workflow.
> > [ ] 4. This is useful, but it needs some adjustments before I can include it in my workflow.
> > [ ] 5. This is really useful! I'm eager to start using it right away. Why didn't you send this earlier? :)
> >
> > Which rating would you select?
>
> For me, this is a "5". I don't currently use gitlab, but I might install it just to test this out.
>
> It looks like there are a large number of YAML files which define the integration between the
> test scripts and gitlab. Also, there are a number of shell scripts to perform some of the setup
> and tests. Do you have any idea how difficult it would be to use the shell scripts outside of
> the CI system (e.g. manually)? That is, are there dependencies between the CI system
> and the shell scripts?

You are effectively the second person I'm aware to provide similar feedback. We
agreed to conduct an effort to remove the gitlab specifics from the script.
Avoid using gitlab CI shell environment in favour of command line arguments.
Also ensure scripts have a "-h" option. This should ease local reproduction and
allow for other CI integration. After all, the Linux kernel is a large community
and gitlab is just one option for managing CI. It is a big system, so we rarely
"just install it" ourself. DRM and Linux Media community are using the
Freedesktop instance, sharing resources and cost within that instance. In Linux
Media we are developing out of tree scripts with similar purpose, but we also
believe a common set of tool, directly in the kernel tree would be a better long
term solution.

>
> I think the convention, of putting this kind of stuff under a "ci" directory, makes sense.
> And it appears that the sub-dir structure allows for other CI systems to add their
> own config and files also.

CI scripts have the particularity of being very granular, which is very unlike
what a human user would prefer. But when CI fails, you really want to know which
small step failed, which can sometimes be hidden by more en-globing scripts. We
also care a lot about parallelism, since we have hundreds of runners available
to execute these tests.

Short answer, I also like that this is under a CI directory, its makes ensure
the purpose and intention of this work is clear.

regards,
Nicolas

Nicolas Dufresne

unread,
Feb 29, 2024, 11:28:57 AMFeb 29
to Nikolai Kondrashov, Guillaume Tucker, Helen Koike, linux...@linuxtv.org, dave....@collabora.com, mri...@kernel.org, linux-...@vger.kernel.org, dri-...@lists.freedesktop.org, linux-k...@vger.kernel.org, gustavo...@collabora.com, paw...@collabora.com, tales.a...@gmail.com, work...@vger.kernel.org, kern...@lists.linux.dev, sk...@linuxfoundation.org, kuni...@googlegroups.com, nfra...@collabora.com, davi...@google.com, co...@inria.fr, Julia....@inria.fr, laur...@collabora.com, ricardo...@collabora.com, ker...@collabora.com, torv...@linuxfoundation.org, gre...@linuxfoundation.org
Hi,
I'd like to add that both CI have a different purpose in the Linux project. This
CI work is a pre-merge verification. Everyone needs to run checkpatch and
smatch, this is automating it (and will catch those that forgot or ran it
incorrectly). But it can go further by effectively testing specific patches on
real hardware (with pretty narrow filters). It will help catch submission issues
earlier, and reduce kernelCI regression rate. As a side effect, kernelCI infra
will endup catching the "integration" issues, which are the issue as a result of
simultenous changes in different trees. They are also often more complex and
benefit from the bisection capabilities.

kernelCI tests are also a lot more intensive, they usually covers everything,
but they bundle multiple changes per run. The pre-merge tests will be reduced to
what seems meaningful for the changes. Its important to understand that pre-
merge CI have a time cost, and we need to make sure CI time does not exceed the
merge window period.

Nicolas

Linus Torvalds

unread,
Feb 29, 2024, 3:21:20 PMFeb 29
to Nikolai Kondrashov, Maxime Ripard, Helen Koike, linux...@linuxtv.org, dave....@collabora.com, linux-...@vger.kernel.org, dri-...@lists.freedesktop.org, linux-k...@vger.kernel.org, gustavo...@collabora.com, paw...@collabora.com, tales.a...@gmail.com, work...@vger.kernel.org, kern...@lists.linux.dev, sk...@linuxfoundation.org, kuni...@googlegroups.com, nfra...@collabora.com, davi...@google.com, co...@inria.fr, Julia....@inria.fr, laur...@collabora.com, ricardo...@collabora.com, ker...@collabora.com, gre...@linuxfoundation.org
On Thu, 29 Feb 2024 at 01:23, Nikolai Kondrashov <spb...@gmail.com> 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.

I would suggest the CI project be separate from the kernel.

And having that slack channel that is restricted to particular
companies is just another sign of this whole disease.

If you want to make a google/microsoft project to do kernel CI, then
more power to you, but don't expect it to be some kind of agreed-upon
kernel project when it's a closed system.

Linus

Nikolai Kondrashov

unread,
Mar 1, 2024, 5:27:19 AMMar 1
to Linus Torvalds, Maxime Ripard, Helen Koike, linux...@linuxtv.org, dave....@collabora.com, linux-...@vger.kernel.org, dri-...@lists.freedesktop.org, linux-k...@vger.kernel.org, gustavo...@collabora.com, paw...@collabora.com, tales.a...@gmail.com, wo