全方位质量保障!龙蜥在内核、软件包、容器镜像、三方模块的 CI 工程实践
怎样提高海量代码的测试和构建效率?
编者按:在海量的代码测试和构建中, 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 流程步骤。
落地实践
由于操作系统版本发布周期相似,联通数科针对社区没有开源部分的设施进行了替换。联通数科整体以 T-One 作为测试核心,基于内部搭建的 git 仓库,建木实现任务调度和触发,koji 实现包构建,最后由 T-One 实现测试。
—— 完 ——
更多推荐
所有评论(0)