关于本地测试和 Github CI 的一些改进意见
YdrMaster opened this issue · 13 comments
-
缓存更多预编译程序
Qemu、musl toolchain 等可以以预编译压缩文件的形式缓存，减少下载和编译的耗时。
-
本地与 CI 的一致性
应该实现本地脚本与 CI 流程的一致性，尤其是应该在本地体现测试矩阵。这样有 2 个好处：
- 提交前方便本地一键测试，发现问题更快；
- CI 出错方便本地复现；
最好的方式是本地直接读取 Github CI 的脚本，复刻 CI 上的运行流程，但不清楚是否有支持这种操作的现成工具。本地也无法支持 CI 那么干净且多样化的环境配置。其次是减少 CI 脚本里的语句，尽量复用本地脚本逻辑。
-
实现方便扩展的测试框架
简化增加测例的步骤或者添加操作指南。
有一部分工作在做了：一个分支。
最好测试出错的时候直接由测试框架打印出一个复现脚本，出了错直接无脑复制粘贴就能再试。
分支的 README 中增加了设计愿景。
我觉得测试集的运行逻辑也应该改改。现在每个测例都要启动 qemu、引导 zCore、运行测例、反馈结果，大量时间花在引导 zCore 上，尤其是 x86_64。如果做成启动一次 zCore 然后运行多个测例直到测试集结束或者内核崩溃呢？这样 x86_64 的运行时间估计能直接缩短 95%。如果不算超时全部测例只要运行两分钟，就算需要刷一刷也没什么关系。
#288 之后，大部分东西都缓存了，除了两个 x86_64 测试集需要 40 分钟，其他所有测试运行时间都在 10 分钟以内。如果把全部测试压到 10 分钟以内，测试框架就有足以支持日常使用的可用性了。
正在恢复 rootfs <- libc-test <- image 的自动递归，以及应对下载/克隆失败的情况。
#292 完全理清了 rootfs 的建立过程。现在可以为使用烧写最小的镜像以节约烧写时间和 flash 空间。
向 rootfs 加入的测例与 CI job 保持一致，也就是说，libc 测试只加入 libc 测例，其他测试只加入其他测例。Action 脚本只需调用一两个指令即可测试，本地对失败测例进行复现也就比较容易了。
-
目前对测试环境的测试：
- Ubuntu20.04/Ubuntu22.04/Debian，但 Ubuntu22.04 无法执行 linux libc test，原因是编译不出测例来
- Qemu6.0~Qemu7.0
-
需要手工安装：
- git
- wget
- git lfs
- rustup
- build-essential
- make
- qemu
- python3
- ...
#325 移除了 alphine，并使得 libos 有自己的 rootfs，这样就不用来回倒腾 x86_64 的 rootfs 了。理论上说现在所有架构的 rootfs 可以并行构建
刚刚增加了一个 toml 配置文件控制不同硬件上的 feature 选择，构建系统进入新时代了