DRM子系统的自动化测试¶

简介¶

当需要测试大量不同的硬件配置时，确保对核心或驱动程序的更改不会引入回归问题可能会非常耗时。此外，对于每个对测试感兴趣的人来说，获取和维护可能大量的硬件是不切实际的。

此外，开发人员最好自行检查代码中的回归问题，而不是依赖维护人员来发现并报告。

在gitlab.freedesktop.org中，有一些设施可以自动测试Mesa，也可以用来测试DRM子系统。本文档解释了有兴趣测试的人员如何使用这种共享基础设施来节省大量时间和精力。

相关文件¶

drivers/gpu/drm/ci/gitlab-ci.yml¶

这是GitLab CI的根配置文件。在其他不太有趣的部分中，它指定了要使用的脚本的特定版本。有一些变量可以修改以更改管道的行为

DRM_CI_PROJECT_PATH: 包含用于CI的Mesa软件基础设施的存储库
DRM_CI_COMMIT_SHA: 要从该存储库使用的特定修订版
UPSTREAM_REPO: 包含目标分支的git存储库的URL
TARGET_BRANCH: 此分支要合并到的分支
IGT_VERSION: 正在使用的igt-gpu-tools的修订版，来自https://gitlab.freedesktop.org/drm/igt-gpu-tools

drivers/gpu/drm/ci/testlist.txt¶

要在所有驱动程序上运行的IGT测试（除非在驱动程序的*-skips.txt文件中提及，请参见下文）。

drivers/gpu/drm/ci/${DRIVER_NAME}-${HW_REVISION}-fails.txt¶

列出了给定驱动程序在特定硬件修订版上的已知失败。

drivers/gpu/drm/ci/${DRIVER_NAME}-${HW_REVISION}-flakes.txt¶

列出了在特定硬件修订版上已知行为不可靠的给定驱动程序的测试。无论结果如何，这些测试都不会导致作业失败。它们仍将运行。

每个新的flake条目都必须与指向报告给受影响驱动程序作者或相关GitLab问题的错误的电子邮件链接相关联。该条目还必须包括板名称或设备树名称、受影响的第一个内核版本、用于测试的IGT版本以及失败率的近似值。

它们应以以下格式提供

# Bug Report: $LORE_URL_OR_GITLAB_ISSUE
# Board Name: broken-board.dtb
# Linux Version: 6.6-rc1
# IGT Version: 1.28-gd2af13d9f
# Failure Rate: 100
flaky-test

使用以下适当的链接创建GitLab问题：amdgpu驱动程序：https://gitlab.freedesktop.org/drm/amd/-/issues i915驱动程序：https://gitlab.freedesktop.org/drm/i915/kernel/-/issues msm驱动程序：https://gitlab.freedesktop.org/drm/msm/-/issues xe驱动程序：https://gitlab.freedesktop.org/drm/xe/kernel/-/issues

drivers/gpu/drm/ci/${DRIVER_NAME}-${HW_REVISION}-skips.txt¶

列出了在特定硬件修订版上不会为给定驱动程序运行的测试。这些通常是由于挂起机器、导致OOM、耗时过长等而干扰测试列表运行的测试。

如何在您的树上启用自动化测试¶

1. 如果您还没有在https://gitlab.freedesktop.org/上创建一个Linux树

2. 在您的内核仓库的配置中（例如https://gitlab.freedesktop.org/janedoe/linux/-/settings/ci_cd），将CI/CD配置文件从.gitlab-ci.yml更改为drivers/gpu/drm/ci/gitlab-ci.yml。

3. 请求加入drm/ci-ok组，以便您的用户拥有在https://gitlab.freedesktop.org/drm/ci-ok上运行CI的必要权限

4. 下次您推送到此存储库时，您将看到正在创建的CI管道（例如https://gitlab.freedesktop.org/janedoe/linux/-/pipelines）

5. 将运行各种作业，并且当管道完成时，除非发现回归问题，否则所有作业都应为绿色。

如何更新测试预期¶

如果您的代码更改修复了任何测试，则必须从drivers/gpu/drm/ci/${DRIVER_NAME}_*_fails.txt中的一个或多个文件中删除一行或多行，对于受更改影响的每个测试平台。

如何扩大覆盖范围¶

如果您的代码更改使得运行更多测试成为可能（例如，通过解决可靠性问题），则可以从flakes和/或skips列表中删除测试，如果有任何已知失败，则删除预期结果。

如果需要更新正在使用的IGT版本（也许您已向其添加了更多测试），请更新gitlab-ci.yml文件顶部的IGT_VERSION变量。

如何测试您对脚本的更改¶

要测试对drm-ci仓库中脚本的更改，请更改drivers/gpu/drm/ci/gitlab-ci.yml中的DRM_CI_PROJECT_PATH和DRM_CI_COMMIT_SHA变量，以匹配您在项目中的fork（例如janedoe/drm-ci）。此fork需要位于https://gitlab.freedesktop.org/中。

如何在您的测试中合并外部修复¶

通常，其他树中的回归问题会阻止测试正在测试的树的本地更改。这些修复将在构建作业期间从目标树中名为${TARGET_BRANCH}-external-fixes的分支中自动合并。

如果管道不在合并请求中，并且本地树中存在具有相同名称的分支，则还将合并该分支中的提交。

如何处理可能关闭的自动化测试实验室¶

如果硬件场关闭，从而导致本来可以通过的管道失败，则可以通过编辑https://gitlab.freedesktop.org/gfx-ci/lab-status/-/blob/main/lab-status.yml上的文件来禁用将提交到该场的所有作业。

Linux内核

目录

本页