全方位质量保障！龙蜥在内核、软件包、容器镜像、三方模块的 CI 工程实践

2024-05-27
陕西
本文字数：2916 字
阅读完需：约 10 分钟

编者按：在海量的代码测试和构建中， CI(Continuous Integration)在代码提交阶段，对提高软件质量和开发效率起到了至关重要的作用。2023 龙蜥操作系统大会全面繁荣开发者生态分论坛上，龙蜥社区 QA SIG Maintainer、联通数科 CUlinux 测试负责人宋彦岭从龙蜥社区质量体系、CI 架构、CI 服务流程及 CI 接入等方面进行介绍，充分展示出社区 CI 在龙蜥开源操作系统质量保障上的重要程度。

(图/龙蜥社区 QA SIG Maintainer、联通数科 CUlinux 测试负责人宋彦岭)

社区质量体系

一般来说，操作系统版本发布周期可以分为三部分：第一是日常开发。日常开发过程中由代码提交触发的 CI 测试，包含 Kernel CI、Package CI、Docker CI、OOT CI，这也是目前 CI 服务体系的四项主要内容。第二是日常集成。该过程中由日常的定时任务来触发 Nightly 测试。第三是产品发布，包含功能、性能、兼容性、稳定性等测试。我们可以看到，作为操作系统服务的第一道防线，CI 测试的意义非常重大：

统一标准规范：所有开发者按照社区标准规范提交代码，既改善了研发流程，又满足开源合规需求。
提前预知缺陷：在代码提交阶段就进行代码测试，提前暴露代码质量问题，减少后续测试压力，提升产品质量。
全自动无感知：在社区提交的 PR 只要符合规范均自动触发 CI 测试，降低开发者使用门槛，提升研发效率。

目前，龙蜥社区 CI 架构如上图，首先社区代码仓库主要来自于 Gitee 或 Github 的公开仓库，这些仓库通过 webhook 接入到社区 CI 服务体系中，接入的仓库若有新事件，如新代码合入、PR 评论等会触发 webhook 消息传递，将消息传递给 git 解析器，解析成标准的数据后进行逻辑处理。其次 CI 通过提前接入体系中的 SDK 去调度具体的任务，例如基于 T-One 平台的测试任务，或基于 ABS 平台的构建任务。最终 T-One、ABS 等平台会将任务结果返回，CI 服务通过标准回调处理，以评论的形式将结果呈现在对应的 PR 上。

在开发者的角度上，该体系由托管在 Gitee 或者 Github 上的代码，基于 CI 机器人、配置中心或 T-One、ABS 平台等基础设施，实现一系列 CI 服务。它处于自动化无感知的状态，更像是一个黑盒子。

CI 基础设施中，有关测试方面的核心在 T-One 测试平台完成，该平台集成了行业内通用的测试用例，如模糊测试、性能测试用例等，也可以由社区开发者自定义一些测试用例加入到 T-One 中，实现自动化运行。目前，T-One 已覆盖业界主流通用 OS 以及混合的硬件架构测试，支持动态扩展，利用动态扩展创建云资源，并且作为测试资源使用。

ABS 作为构建核心平台，覆盖 Anolis OS 及主流的硬件架构，可以实现对社区开源软件包的构建，同时将构建成功的软件包对象发布到公网环境中。

社区 CI 体系特色分为四大部分：第一是分层分级，针对不同仓库可以进行分层分级处理，普通仓库提供基本 CI 测试，核心仓库提供定制化的 CI 测试能力。第二是可拓展框架，CI 工具提供了插件化能力，多种工具可以组合产生联动效果，其中新增功能可以通过插件进行快速扩展。第三是接入能力，提供高度开放的接入能力，可以让开发者自定义开发测试来接入 CI 服务体系。第四是 CI/CD 服务一体化，提供 PR 合入后的后续操作，根据仓库类型不同提供不同的处理能力。

CI 服务流程

CI 服务阶段从代码提交到触发 CI 测试，再由 reviewer 评审，测试失败后需要进行重新测试，也可以通过评论方式重新触发测试，评审通过则会合入 PR。

在上文中提到，CI 测试流程共有 Kernel CI、Package CI、Docker CI、OOT CI 4 种。Kernel CI 针对内核做 CI 测试，目前主要监测存放在 Gitee 上的 Cloud Kernel 仓库，若 4.19、5.10、6.6 三个内核一旦有新的代码合入，由 CI 机器人进行检查 CLA 签署协议以及 PR 信息是否符合规范。再通过 CBC 工具以及 T-One 测试平台对新提交的 PR 进行测试，检测没有问题后，CI 机器人合入 PR 到指定仓库并进行自动签名操作。

CBC 与 T-One 测试部分主要测试项详见下图：

针对软件包的 Package CI，对存放在 Gitee 上的 src-anolis-os、src-anolis-sig、src-anolis-module、src-anolis-ai 等多个仓库组下的所有仓库进行检测。一旦发现新提交的 PR，先对基本信息进行检测，由 T-One 进行合规检查和代码检查，检查测试无误后由 ABS 构建出初步使用的软件包，再交给 T-One 做冒烟测试。后续如果没有问题，最后再由 ABS 构建出正式的软件包，并推送到 mirrors 仓库中。

Package CI 整个测试项详见下图：

针对容器镜像的 Docker CI，检测 baseos、app、dragonwell、language 存放在 Gitee 和 Github 公开仓库的容器仓库，一旦有新的 PR，会检查 CLA 和容器的配置文件，检测没有问题后，会先通过 ABS 构建出测试使用的容器，由 T-One 做进一步测试，测试没有问题会合入，通过 ABS 构建出正式的镜像，推送到公网的镜像仓库中。

对于容器的测试详见下图：

针对内核的第三方模块做的 CI 测试 - OOT CI ，检测仓库主要在 anolis 下以 kmod 开头的第三方模块的仓库，这些仓库中有新的 PR 产生，（该测试更轻量，与内核测试类似）先检查 CLA，通过 T-One 进行 checkpatch 检查和生成临时分支 rpm tree，然后通过 ABS 构建出新的 OOT 模块进行测试。

社区 CI 接入

下面介绍社区的开发者来自定义去接入 CI 流程的方法。首先在 Gitee 上建立了一个仓库 ci-meta，是针对 CI 服务体系建立的 CI 配置中心。仓库目录结构如下图，主要包括公共配置和开发者自定义的配置两大部分。其中公共配置中包含三部分：产品相关的配置、 T-One 平台测试配置、全局仓库配置，其中仓库配置中包含了代码检查、ABS 构建的选项、依赖测试等。

若开发者想自己定义新的 CI 测试，则需要定义 CI 的 yaml 文件，将其存放在 CI 配置中心，其中的自定义目录 repos 则会根据首字母建立不同的目录，将相对应的软件包 CI yaml 文件存放，就可以接入到社区的 CI 服务中进行测试。该文件中的组成分为三部分，包括仓库配置、测试配置和通知配置。若在 ci.yaml 缺失的情况下，默认引用全局配置，包括与 T-One 的交互或自定义的参数。通知配置目前支持两种方式：邮件和钉钉，集成接入后在指定状态时进行通知。

目前，在上述四种 CI 服务中，Kernel CI 和 Package CI 属于常用服务，拦截了大量有问题的 PR，检测了 6.5 万 + patch，拦截了 1 万+ patch，通过 T-One 平台发起了 7 万+ 测试任务，通过 ABS 平台发起了 2.1 万＋构建任务。

未来，社区关于 CI 服务体系发展有以下展望：第一方面扩大支撑，未来会支持更多仓库来进行定制化的 CI 测试，提供更强大的测试能力。第二部分是可视化，希望打造一个全新的可视化 web 界面，帮助开发者理解和纵览社区服务，也降低接入 CI 体系的难度，通过可视化界面来完成点击接入方式。第三部分完善接入，提供体验更好的接入方式，提供更多的 CI 模式，完善开源社区的 CI 服务体系。第四部分是能力开放，提供工具封装级别的插件支持，允许开发者自定义 CI 测试流程和工具模组，自行组装和定制化 CI 流程步骤。