Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
New issues: - [High] The CI configuration hardcodes `FDO_UPSTREAM_REPO` to a personal repository (`mripard/kernel`), breaking fork-based workflows and pointing the subsystem's CI to a personal fork. Pre-existing issues: - [High] The `kunit:arm64` job attempts to install `qemu-system-aarch64`, which is not a valid Debian package, breaking the ARM64 KUnit pipeline. -- commit 1c7dfd00b5030cd66091b90d1334fd1443f5c314 Author: Maxime Ripard <[email protected]> drm/ci: Add CI pipeline for drm-misc branches Introduce a CI entry point that runs on pushes to drm-misc branches. The pipeline cross-compiles the kernel using LLVM on a Debian container, runs DRM KUnit tests, and checks device tree bindings. Link: https://lore.kernel.org/all/20250319-greedy-sturgeon-from-avalon-ac758f@houat/ > diff --git a/drivers/gpu/drm/ci/drm-misc-ci.yml > b/drivers/gpu/drm/ci/drm-misc-ci.yml > new file mode 100644 > index 0000000000000..4ab87547794e8 > --- /dev/null > +++ b/drivers/gpu/drm/ci/drm-misc-ci.yml [ ... ] > +variables: > + CI_TEMPLATES_COMMIT: &ci-templates-commit > aec7a6ce7bb38902c70641526f6611e27141784a > + # Project whose container registry stores the built images > + FDO_UPSTREAM_REPO: mripard/kernel [Severity: High] Does this hardcoded personal repository break fork-based CI workflows? If a developer modifies the container in their own fork and updates the tag, the build step will push the container to their registry. However, downstream jobs using the .build-base template will still attempt to pull from the mripard/kernel path because of how FDO_UPSTREAM_REPO is used here: .build-base: image: "${CI_REGISTRY}/${FDO_UPSTREAM_REPO}/debian/trixie:${KERNEL_BUILD_CONTAINER_TAG}" Should this variable be set to the generic upstream project path instead? > + KERNEL_BUILD_CONTAINER_TAG: "2026-09-11-01" > + LLVM_VERSION: "19" > + > +default: > + before_script: [] > + > +include: > + - project: 'freedesktop/ci-templates' > + ref: *ci-templates-commit > + file: > + - '/templates/debian.yml' > + - local: drivers/gpu/drm/ci/check-devicetrees.yml > + - local: drivers/gpu/drm/ci/kunit.yml [Severity: High] This is a pre-existing issue, but including kunit.yml here exposes a failure in the kunit:arm64 job. That job contains the following step in its before_script: apt-get install -y --no-install-recommends qemu-system-aarch64 Is this package name correct? On Debian systems, the emulator for AArch64 is typically provided by the qemu-system-arm package. Attempting to install qemu-system-aarch64 directly will fail and break the ARM64 KUnit pipeline run when executed inside this Debian environment. [ ... ] -- Sashiko AI review ยท https://sashiko.dev/#/patchset/[email protected]?part=1
