操作系统云原生容器运行时【免费下载链接】linuxkitA toolkit for building secure, portable and lean operating systems for containers项目地址https://gitcode.com/gh_mirrors/li/linuxkit点击查看免费下载LinuxKit 是一个用于构建安全、可移植、精简容器操作系统的工具链其质量保障体系由一套基于 rtf 为主线结合仓库内test/cases的真实用例、test/Makefile与根 Makefile 的 CI 目标完整讲解测试框架的安装、测试的筛选与运行、新用例的编写规范以及 PR、分支、Tag 三种场景下的云端 CI 流程帮助你掌握 LinuxKit 测试体系的全部环节并能在本地复现。测试框架与工具链准备LinuxKit 的测试套件依赖 rtf 这个外部测试框架。rtf 是一个面向 shell 脚本测试的 Go 工具负责解析test/cases目录中的分组与用例、按标签筛选、执行测试并汇总结果。安装方式很简单make bin/rtf make install从根目录 Makefile 可以看到 rtf 的实际构建细节它通过固定 commitRTF_COMMIT1118e08445438dc37ec62b4c1e216918b3d804d2拉取源码并用仓库内置的linuxkit/go-compile容器镜像在 Docker 中交叉编译最终产出bin/rtfWindows 下为bin/rtf.exemake install将其复制到$(PREFIX)/bin默认/usr/local/bin。RTF_COMMIT1118e08445438dc37ec62b4c1e216918b3d804d2 RTF_CMDgithub.com/linuxkit/rtf/cmd $(RTF): tmp_rtf_bin.tar | bin tar -C $(dir $(RTF)) -xf $ rm $ touch $ tmp_rtf_bin.tar: Makefile docker run --rm --log-drivernone -e http_proxy$(http_proxy) -e https_proxy$(https_proxy) $(CROSS) $(GO_COMPILE) --clone-path github.com/linuxkit/rtf --clone https://github.com/linuxkit/rtf.git --commit $(RTF_COMMIT) --package github.com/linuxkit/rtf --ldflags -X $(RTF_CMD).GitCommit$(RTF_COMMIT) -X $(RTF_CMD).Version$(RTF_VERSION) -o $(notdir $(RTF)) $这意味着构建 rtf 需要本机具备可用的 Docker 环境用于运行 go-compile 容器与 Go 工具链。make install之后rtf命令即可全局使用。若想绕过安装直接使用仓库 test/Makefile 的check-deps目标还会校验linuxkit与rtf两个二进制是否存在于 PATH 中check-deps: ifndef LINUXKIT $(error linuxkit binary not found. please install it.) endif ifndef RTF $(error rtf is not available. please install it!) endif运行测试套件进入test目录即可运行全部测试cd test rtf -v run -x-v启用详细输出实时显示每个用例的执行过程run执行测试-x遇到失败即停止fail-fast便于快速定位首个故障点。测试结束后结果会汇总写入_results目录包括每个用例的执行状态、输出日志以及整体 PASS/FAIL 判定。需要说明的是test/Makefile中的test目标等价于test: rtf -l build -v2 run -x $(TEST_SUITE) $(TEST_SHARD_ARG)即仓库默认会附加-l build标签过滤并支持两个环境变量对测试范围做精细控制TEST_SUITE指定要运行的测试名称模式空表示全部TEST_SHARD按this/total格式切分测试例如1/10表示10 个分片中的第 1 片适用于大规模并行调度。该变量会转换为 rtf 的-s参数ifneq ($(TEST_SHARD),) override TEST_SHARD_ARG-s $(TEST_SHARD) endif因此在仓库根目录执行make test TEST_SUITElinuxkit.build TEST_SHARD2/4这类组合命令即可完成指定用例的分片运行。用标签控制测试范围不同用例的运行成本差异巨大有的只需本地构建几秒有的要启动完整虚拟机甚至访问云平台。rtf 的运行控制基于标签labels与模式匹配实现。为用例打上标签后可用-l参数仅运行特定标签的用例rtf -v -l slow run -x例如 CI 中默认通过-l build只跑构建类用例见上文test目标而需要真实平台验证的用例则通过gcp、amd64等标签单独调度。列出将被执行的测试运行前可以先用rtf list预览当前将被执行的测试清单rtf list列表中每个用例对应一个LABELS列。部分测试可能被标记为SKIP此时LABELS列通常会给出跳过原因例如amd64表示仅在 amd64 架构上有效skip表示该用例在当前环境被显式跳过。仓库中这类标注随处可见例如 test/cases/000_build/000_formats/001_iso-bios/test.sh 标注# LABELS: amd64而 test/cases/000_build/000_formats/006_vhd/test.sh 直接标注# LABELS: skip表明 VHD 格式用例在多数 CI 环境被跳过。按名称模式匹配rtf 还支持以名称模式过滤用例例如只运行构建相关测试rtf -v run -x linuxkit.build模式会匹配用例的名称路径如000_build/010_reproducible/...这与test/Makefile中TEST_SUITE的语义一致——make test TEST_SUITElinuxkit.build与上述命令等价。编写新的测试用例第一步决定分组归属新用例加入前先查看 test/cases 目录确认现有分组避免重复造轮子。当前仓库包含以下分组分组目录关注点test/cases/000_build镜像构建输出格式、可复现性、binds、构建参数、SBOM、Dockerfile 校验等test/cases/010_platforms平台运行qemu 启动、各种磁盘/镜像格式、AWS 等云平台test/cases/020_kernel内核相关内核配置、启动参数、不同内核版本行为test/cases/030_security安全特性验证test/cases/040_packagespkg 包构建与行为分组可以嵌套仓库已有大量嵌套实例例如000_build/000_formats/000_kernelinitrd。分组顺序通过数字前缀控制000起始数字越小越先执行。第二步创建分组如确有必要如需新建分组使用000_name命名规范000为期望的执行顺序name为分组名mkdir 000_name然后将现有的 test/cases/group.sh 复制进新分组并调整或参考 rtf 官方模板group.sh。分组脚本定义了group_init与group_deinit两个钩子分别在分组内所有用例运行前/后调用。以仓库顶层 group.sh 为例它负责清理并重建临时目录LINUXKIT_TMPDIR将LINUXKIT_EXAMPLES_DIR指向仓库根目录的 examples写入${LINUXKIT_TMPDIR}/env.sh供各用例通过 test/cases/_lib/lib.sh 加载若启用了gcp标签则检查环境变量CLOUDSDK_CORE_PROJECT是否配置未配置直接返回失败if rt_label_set gcp; then # If we run GCP tests, make sure it is configured if [ -z ${CLOUDSDK_CORE_PROJECT} ]; then echo GCP does not seem to be configured return 1 fi fi第三步编写用例脚本在分组目录下同样以000_name格式创建用例文件夹将现有test.sh复制进去修改或参考 rtf 的test.sh模板。每个test.sh的头部通过注释声明元信息#!/bin/sh # SUMMARY: 用例功能的一句话描述 # LABELS: amd64 # 标签可空skip 表示跳过amd64 表示仅 amd64 架构 # REPEAT: # 可选重复执行次数以下是一个真实的最小用例test/cases/000_build/000_formats/000_kernelinitrd/test.sh它验证kernelinitrd输出格式会生成三个产物文件#!/bin/sh # SUMMARY: Check that kernelinitrd output format is generated # LABELS: set -e # Source libraries. Uncomment if needed/defined . ${RT_PROJECT_ROOT}/_lib/lib.sh NAMEcheck clean_up() { rm -f ${NAME}* } trap clean_up EXIT linuxkit build --format kernelinitrd --name ${NAME} ../test.yml [ -f ${NAME}-kernel ] || exit 1 [ -f ${NAME}-initrd.img ] || exit 1 [ -f ${NAME}-cmdline ] || exit 1 exit 0要点解读用例基于set -e保证任一命令失败即中断最终exit 0表示通过通过${RT_PROJECT_ROOT}引用测试项目根加载公共库 lib.shtrap clean_up EXIT确保临时产物被清理避免污染后续用例前置条件不满足时用exit 1表示失败若需预期失败场景则捕获命令输出并断言见 test/cases/000_build/090_validate_build_yaml/test.shRESULT$(linuxkit pkg build --force . 21 || echo FAILED) if [ ${RESULT} ! FAILED ]; then echo Build should have failed with invalid yaml, instead was ${RESULT} fi echo Summary: correctly detected invalid yaml exit 0该用例故意用非法 YAML 触发构建失败再断言确实失败属于负向验证的经典写法。公共库 lib.sh 还提供linuxkitrun辅助函数将linuxkit run的输出同时 tee 到 stderr确保日志不丢失linuxkitrun() { linuxkit run $ | tee /dev/stderr }第四步为条件性用例打标签如果用例只能在特定条件下运行如特定架构、需要云平台凭据、执行时间过长应当为其添加标签以避免默认执行并在测试文档中说明该标签的用途。例如仓库中大量用例标注amd64仅 x86_64 有效云平台类标注gcp特殊场景标注skip。这样 CI 才能用-l build、-l gcp等参数按需调度。持续集成CI体系概览LinuxKit 的 CI 基于 DatakitCI 搭建其流水线配置存放于独立的 linuxkit-ci 配置仓库中测试日志既可以通过 CI 页面的Details链接查看也可以访问专门的测试日志站点浏览原始日志原始日志还会按分支归档存储每个分支对应一次特定运行的结果。当前文档明确提示这套 CI 架构很快会有重大调整阅读时请注意时效性。CI 分为三条流水线分别覆盖 PR、分支、Tag 三种触发场景其核心执行逻辑都定义在根目录 Makefile 中ci: test-cross $(MAKE) $(MAKE) install $(MAKE) -C test all $(MAKE) -C pkg build ci-tag: test-cross $(MAKE) $(MAKE) install $(MAKE) -C test all $(MAKE) -C pkg build ci-pr: test-cross $(MAKE) $(MAKE) install $(MAKE) -C test pr $(MAKE) -C pkg build三者共同的骨架是先执行test-cross对 src/cmd/linuxkit 做跨平台编译检查再构建主程序、安装随后运行测试最后构建全部 pkg 镜像。差异在于测试范围ci/ci-tag使用make -C test all等于test-pr ltp见 test/Makefile而ci-pr只跑make -C test prPR 阶段不跑 LTP以控制耗时。PR 测试流程每个 PR 都会在 Google Cloud PlatformGCP上临时创建的一次性虚拟机上执行测试该虚拟机不持有任何访问 GCP 或其他云平台的权限或凭据从源头避免测试机越权LinuxKit CI 在虚拟机内执行make ci-pr用 rtf 跑测试随后将_results结果目录通过scp回传给控制节点测试结果写入 Datakit 以便后续查询访问同时./artifacts目录也被scp回传测试通过后进入内核配置验证环节CI 使用 Python 脚本将./artifacts/test.img.tar.gz制作为 GCP 镜像启动该镜像并在日志中 grep 成功消息对应 test/hack/test.yml 中check-kernel-config容器输出的成功提示以此确认内核配置镜像能在 GCP 上正常运行。make ci-pr用到的pr目标在 test/Makefile 中定义为test-pr: test即构建类测试 可选的 suite/shards 参数与完整 CI 的取舍关系一目了然。分支与 Tag 测试流程分支和 Tag 的测试在一台常驻于 GCP 的专用机器上执行LinuxKit CI 分别运行make ci分支或make ci-tagTag 发布同样用 rtf 跑测试并把_results通过 scp 回传结果存入 Datakit测试通过后执行与 PR 相同的 GCP 镜像验证步骤最后 CI 运行make test-ltp执行 Linux Test ProjectLTP测试套件对内核做深度的系统调用与行为回归验证。LTP 目标的实现同样在 test/Makefile 中它利用 test/hack/test-ltp.yml 构建 GCP 镜像并启动n1-highcpu-4机器运行最后用grep校验日志中的test suite PASSEDltp: export CLOUDSDK_IMAGE_NAME?test-ltp ltp: $(LINUXKIT) test-ltp.img.tar.gz $(LINUXKIT) build --format gcp -pull hack/test-ltp.yml $(LINUXKIT) push gcp test-ltp.img.tar.gz $(LINUXKIT) run gcp -skip-cleanup -machine n1-highcpu-4 $(CLOUDSDK_IMAGE_NAME) | tee test-ltp.log $(call check_test_log, test-ltp.log)注意 LTP 需要gcloud环境与 GCP 项目配置CLOUDSDK_CORE_PROJECT且依赖仓库内置的 linuxkit 二进制因此在普通开发机上默认不会执行。本地复现 CI 的关键步骤结合上文可在本地大致复现 CI 的测试环节# 1. 准备工具编译并安装 linuxkit 与 rtf make linuxkit bin/rtf make install # 2. 进入测试目录运行构建类测试对应 ci-pr 的 pr 阶段 cd test rtf -l build -v2 run -x # 3. 只跑某类用例 rtf -v run -x linuxkit.build # 4. 预览将被执行的用例 rtf list如需连 GCP 验证模拟 PR 的镜像验证环节需先配置gcloud并设置CLOUDSDK_CORE_PROJECT再参考 test/hack/test.yml 中的内核配置测试镜像定义——该文件刻意沿用check-kernel-config容器正是因为 CI 目前依赖其中的成功消息字符串做日志断言。小结LinuxKit 的测试与 CI 体系可以概括为三层rtf 驱动的本地回归套件标签、模式匹配、分片与_results报告、规范化的用例编写流程000_name分组、group.sh钩子、test.sh元信息注释与公共库 lib.sh以及GCP 上的三级 CI 流水线PR 的make ci-pr、分支的make ci、Tag 的make ci-tag与最终的make test-ltp。任何改动只要遵循上述约定就能自动纳入这套从构建、平台运行到内核深测的完整回归体系。赞分享操作系统云原生容器运行时【免费下载链接】linuxkitA toolkit for building secure, portable and lean operating systems for containers项目地址https://gitcode.com/gh_mirrors/li/linuxkit点击查看免费下载相关推荐Kubernetes 端到端E2E测试实战指南从 kubetest 运行到测试用例编写与 CI 集成Kubernetes 端到端E2E测试实战指南从 kubetest 运行到测试用例编写与 CI 集成 端到端E2E测试是 Kubernetes 社区验开源治理文档研发协作Ralph for Claude Code 测试指南基于 BATS 的 276 测试套件架构、编写规范与 CI/CD 实战Ralph for Claude Code 测试指南基于 BATS 的 276 测试套件架构、编写规范与 CI/CD 实战 本文是 ralph claude人工智能AI 应用自主智能体CLI开发工具Milvus 集成测试框架实战指南基于 MiniClusterV3 的端到端测试编写与运行Milvus 集成测试框架实战指南基于 MiniClusterV3 的端到端测试编写与运行 本文基于 Milvus 仓库的 tests/integration数据库向量数据库分布式数据库后端上一篇Jet Bridge团队权限管理完整指南如何设置安全的多用户协作环境下一篇用NCU剖析FlashKDA从kernel耗时到warp stall的完整流程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 LinuxKit 测试与 CI 实战指南：基于 rtf 的测试套件、用例编写与云端持续集成
操作系统云原生容器运行时【免费下载链接】linuxkitA toolkit for building secure, portable and lean operating systems for containers项目地址https://gitcode.com/gh_mirrors/li/linuxkit点击查看免费下载LinuxKit 是一个用于构建安全、可移植、精简容器操作系统的工具链其质量保障体系由一套基于 rtf 为主线结合仓库内test/cases的真实用例、test/Makefile与根 Makefile 的 CI 目标完整讲解测试框架的安装、测试的筛选与运行、新用例的编写规范以及 PR、分支、Tag 三种场景下的云端 CI 流程帮助你掌握 LinuxKit 测试体系的全部环节并能在本地复现。测试框架与工具链准备LinuxKit 的测试套件依赖 rtf 这个外部测试框架。rtf 是一个面向 shell 脚本测试的 Go 工具负责解析test/cases目录中的分组与用例、按标签筛选、执行测试并汇总结果。安装方式很简单make bin/rtf make install从根目录 Makefile 可以看到 rtf 的实际构建细节它通过固定 commitRTF_COMMIT1118e08445438dc37ec62b4c1e216918b3d804d2拉取源码并用仓库内置的linuxkit/go-compile容器镜像在 Docker 中交叉编译最终产出bin/rtfWindows 下为bin/rtf.exemake install将其复制到$(PREFIX)/bin默认/usr/local/bin。RTF_COMMIT1118e08445438dc37ec62b4c1e216918b3d804d2 RTF_CMDgithub.com/linuxkit/rtf/cmd $(RTF): tmp_rtf_bin.tar | bin tar -C $(dir $(RTF)) -xf $ rm $ touch $ tmp_rtf_bin.tar: Makefile docker run --rm --log-drivernone -e http_proxy$(http_proxy) -e https_proxy$(https_proxy) $(CROSS) $(GO_COMPILE) --clone-path github.com/linuxkit/rtf --clone https://github.com/linuxkit/rtf.git --commit $(RTF_COMMIT) --package github.com/linuxkit/rtf --ldflags -X $(RTF_CMD).GitCommit$(RTF_COMMIT) -X $(RTF_CMD).Version$(RTF_VERSION) -o $(notdir $(RTF)) $这意味着构建 rtf 需要本机具备可用的 Docker 环境用于运行 go-compile 容器与 Go 工具链。make install之后rtf命令即可全局使用。若想绕过安装直接使用仓库 test/Makefile 的check-deps目标还会校验linuxkit与rtf两个二进制是否存在于 PATH 中check-deps: ifndef LINUXKIT $(error linuxkit binary not found. please install it.) endif ifndef RTF $(error rtf is not available. please install it!) endif运行测试套件进入test目录即可运行全部测试cd test rtf -v run -x-v启用详细输出实时显示每个用例的执行过程run执行测试-x遇到失败即停止fail-fast便于快速定位首个故障点。测试结束后结果会汇总写入_results目录包括每个用例的执行状态、输出日志以及整体 PASS/FAIL 判定。需要说明的是test/Makefile中的test目标等价于test: rtf -l build -v2 run -x $(TEST_SUITE) $(TEST_SHARD_ARG)即仓库默认会附加-l build标签过滤并支持两个环境变量对测试范围做精细控制TEST_SUITE指定要运行的测试名称模式空表示全部TEST_SHARD按this/total格式切分测试例如1/10表示10 个分片中的第 1 片适用于大规模并行调度。该变量会转换为 rtf 的-s参数ifneq ($(TEST_SHARD),) override TEST_SHARD_ARG-s $(TEST_SHARD) endif因此在仓库根目录执行make test TEST_SUITElinuxkit.build TEST_SHARD2/4这类组合命令即可完成指定用例的分片运行。用标签控制测试范围不同用例的运行成本差异巨大有的只需本地构建几秒有的要启动完整虚拟机甚至访问云平台。rtf 的运行控制基于标签labels与模式匹配实现。为用例打上标签后可用-l参数仅运行特定标签的用例rtf -v -l slow run -x例如 CI 中默认通过-l build只跑构建类用例见上文test目标而需要真实平台验证的用例则通过gcp、amd64等标签单独调度。列出将被执行的测试运行前可以先用rtf list预览当前将被执行的测试清单rtf list列表中每个用例对应一个LABELS列。部分测试可能被标记为SKIP此时LABELS列通常会给出跳过原因例如amd64表示仅在 amd64 架构上有效skip表示该用例在当前环境被显式跳过。仓库中这类标注随处可见例如 test/cases/000_build/000_formats/001_iso-bios/test.sh 标注# LABELS: amd64而 test/cases/000_build/000_formats/006_vhd/test.sh 直接标注# LABELS: skip表明 VHD 格式用例在多数 CI 环境被跳过。按名称模式匹配rtf 还支持以名称模式过滤用例例如只运行构建相关测试rtf -v run -x linuxkit.build模式会匹配用例的名称路径如000_build/010_reproducible/...这与test/Makefile中TEST_SUITE的语义一致——make test TEST_SUITElinuxkit.build与上述命令等价。编写新的测试用例第一步决定分组归属新用例加入前先查看 test/cases 目录确认现有分组避免重复造轮子。当前仓库包含以下分组分组目录关注点test/cases/000_build镜像构建输出格式、可复现性、binds、构建参数、SBOM、Dockerfile 校验等test/cases/010_platforms平台运行qemu 启动、各种磁盘/镜像格式、AWS 等云平台test/cases/020_kernel内核相关内核配置、启动参数、不同内核版本行为test/cases/030_security安全特性验证test/cases/040_packagespkg 包构建与行为分组可以嵌套仓库已有大量嵌套实例例如000_build/000_formats/000_kernelinitrd。分组顺序通过数字前缀控制000起始数字越小越先执行。第二步创建分组如确有必要如需新建分组使用000_name命名规范000为期望的执行顺序name为分组名mkdir 000_name然后将现有的 test/cases/group.sh 复制进新分组并调整或参考 rtf 官方模板group.sh。分组脚本定义了group_init与group_deinit两个钩子分别在分组内所有用例运行前/后调用。以仓库顶层 group.sh 为例它负责清理并重建临时目录LINUXKIT_TMPDIR将LINUXKIT_EXAMPLES_DIR指向仓库根目录的 examples写入${LINUXKIT_TMPDIR}/env.sh供各用例通过 test/cases/_lib/lib.sh 加载若启用了gcp标签则检查环境变量CLOUDSDK_CORE_PROJECT是否配置未配置直接返回失败if rt_label_set gcp; then # If we run GCP tests, make sure it is configured if [ -z ${CLOUDSDK_CORE_PROJECT} ]; then echo GCP does not seem to be configured return 1 fi fi第三步编写用例脚本在分组目录下同样以000_name格式创建用例文件夹将现有test.sh复制进去修改或参考 rtf 的test.sh模板。每个test.sh的头部通过注释声明元信息#!/bin/sh # SUMMARY: 用例功能的一句话描述 # LABELS: amd64 # 标签可空skip 表示跳过amd64 表示仅 amd64 架构 # REPEAT: # 可选重复执行次数以下是一个真实的最小用例test/cases/000_build/000_formats/000_kernelinitrd/test.sh它验证kernelinitrd输出格式会生成三个产物文件#!/bin/sh # SUMMARY: Check that kernelinitrd output format is generated # LABELS: set -e # Source libraries. Uncomment if needed/defined . ${RT_PROJECT_ROOT}/_lib/lib.sh NAMEcheck clean_up() { rm -f ${NAME}* } trap clean_up EXIT linuxkit build --format kernelinitrd --name ${NAME} ../test.yml [ -f ${NAME}-kernel ] || exit 1 [ -f ${NAME}-initrd.img ] || exit 1 [ -f ${NAME}-cmdline ] || exit 1 exit 0要点解读用例基于set -e保证任一命令失败即中断最终exit 0表示通过通过${RT_PROJECT_ROOT}引用测试项目根加载公共库 lib.shtrap clean_up EXIT确保临时产物被清理避免污染后续用例前置条件不满足时用exit 1表示失败若需预期失败场景则捕获命令输出并断言见 test/cases/000_build/090_validate_build_yaml/test.shRESULT$(linuxkit pkg build --force . 21 || echo FAILED) if [ ${RESULT} ! FAILED ]; then echo Build should have failed with invalid yaml, instead was ${RESULT} fi echo Summary: correctly detected invalid yaml exit 0该用例故意用非法 YAML 触发构建失败再断言确实失败属于负向验证的经典写法。公共库 lib.sh 还提供linuxkitrun辅助函数将linuxkit run的输出同时 tee 到 stderr确保日志不丢失linuxkitrun() { linuxkit run $ | tee /dev/stderr }第四步为条件性用例打标签如果用例只能在特定条件下运行如特定架构、需要云平台凭据、执行时间过长应当为其添加标签以避免默认执行并在测试文档中说明该标签的用途。例如仓库中大量用例标注amd64仅 x86_64 有效云平台类标注gcp特殊场景标注skip。这样 CI 才能用-l build、-l gcp等参数按需调度。持续集成CI体系概览LinuxKit 的 CI 基于 DatakitCI 搭建其流水线配置存放于独立的 linuxkit-ci 配置仓库中测试日志既可以通过 CI 页面的Details链接查看也可以访问专门的测试日志站点浏览原始日志原始日志还会按分支归档存储每个分支对应一次特定运行的结果。当前文档明确提示这套 CI 架构很快会有重大调整阅读时请注意时效性。CI 分为三条流水线分别覆盖 PR、分支、Tag 三种触发场景其核心执行逻辑都定义在根目录 Makefile 中ci: test-cross $(MAKE) $(MAKE) install $(MAKE) -C test all $(MAKE) -C pkg build ci-tag: test-cross $(MAKE) $(MAKE) install $(MAKE) -C test all $(MAKE) -C pkg build ci-pr: test-cross $(MAKE) $(MAKE) install $(MAKE) -C test pr $(MAKE) -C pkg build三者共同的骨架是先执行test-cross对 src/cmd/linuxkit 做跨平台编译检查再构建主程序、安装随后运行测试最后构建全部 pkg 镜像。差异在于测试范围ci/ci-tag使用make -C test all等于test-pr ltp见 test/Makefile而ci-pr只跑make -C test prPR 阶段不跑 LTP以控制耗时。PR 测试流程每个 PR 都会在 Google Cloud PlatformGCP上临时创建的一次性虚拟机上执行测试该虚拟机不持有任何访问 GCP 或其他云平台的权限或凭据从源头避免测试机越权LinuxKit CI 在虚拟机内执行make ci-pr用 rtf 跑测试随后将_results结果目录通过scp回传给控制节点测试结果写入 Datakit 以便后续查询访问同时./artifacts目录也被scp回传测试通过后进入内核配置验证环节CI 使用 Python 脚本将./artifacts/test.img.tar.gz制作为 GCP 镜像启动该镜像并在日志中 grep 成功消息对应 test/hack/test.yml 中check-kernel-config容器输出的成功提示以此确认内核配置镜像能在 GCP 上正常运行。make ci-pr用到的pr目标在 test/Makefile 中定义为test-pr: test即构建类测试 可选的 suite/shards 参数与完整 CI 的取舍关系一目了然。分支与 Tag 测试流程分支和 Tag 的测试在一台常驻于 GCP 的专用机器上执行LinuxKit CI 分别运行make ci分支或make ci-tagTag 发布同样用 rtf 跑测试并把_results通过 scp 回传结果存入 Datakit测试通过后执行与 PR 相同的 GCP 镜像验证步骤最后 CI 运行make test-ltp执行 Linux Test ProjectLTP测试套件对内核做深度的系统调用与行为回归验证。LTP 目标的实现同样在 test/Makefile 中它利用 test/hack/test-ltp.yml 构建 GCP 镜像并启动n1-highcpu-4机器运行最后用grep校验日志中的test suite PASSEDltp: export CLOUDSDK_IMAGE_NAME?test-ltp ltp: $(LINUXKIT) test-ltp.img.tar.gz $(LINUXKIT) build --format gcp -pull hack/test-ltp.yml $(LINUXKIT) push gcp test-ltp.img.tar.gz $(LINUXKIT) run gcp -skip-cleanup -machine n1-highcpu-4 $(CLOUDSDK_IMAGE_NAME) | tee test-ltp.log $(call check_test_log, test-ltp.log)注意 LTP 需要gcloud环境与 GCP 项目配置CLOUDSDK_CORE_PROJECT且依赖仓库内置的 linuxkit 二进制因此在普通开发机上默认不会执行。本地复现 CI 的关键步骤结合上文可在本地大致复现 CI 的测试环节# 1. 准备工具编译并安装 linuxkit 与 rtf make linuxkit bin/rtf make install # 2. 进入测试目录运行构建类测试对应 ci-pr 的 pr 阶段 cd test rtf -l build -v2 run -x # 3. 只跑某类用例 rtf -v run -x linuxkit.build # 4. 预览将被执行的用例 rtf list如需连 GCP 验证模拟 PR 的镜像验证环节需先配置gcloud并设置CLOUDSDK_CORE_PROJECT再参考 test/hack/test.yml 中的内核配置测试镜像定义——该文件刻意沿用check-kernel-config容器正是因为 CI 目前依赖其中的成功消息字符串做日志断言。小结LinuxKit 的测试与 CI 体系可以概括为三层rtf 驱动的本地回归套件标签、模式匹配、分片与_results报告、规范化的用例编写流程000_name分组、group.sh钩子、test.sh元信息注释与公共库 lib.sh以及GCP 上的三级 CI 流水线PR 的make ci-pr、分支的make ci、Tag 的make ci-tag与最终的make test-ltp。任何改动只要遵循上述约定就能自动纳入这套从构建、平台运行到内核深测的完整回归体系。赞分享操作系统云原生容器运行时【免费下载链接】linuxkitA toolkit for building secure, portable and lean operating systems for containers项目地址https://gitcode.com/gh_mirrors/li/linuxkit点击查看免费下载相关推荐Kubernetes 端到端E2E测试实战指南从 kubetest 运行到测试用例编写与 CI 集成Kubernetes 端到端E2E测试实战指南从 kubetest 运行到测试用例编写与 CI 集成 端到端E2E测试是 Kubernetes 社区验开源治理文档研发协作Ralph for Claude Code 测试指南基于 BATS 的 276 测试套件架构、编写规范与 CI/CD 实战Ralph for Claude Code 测试指南基于 BATS 的 276 测试套件架构、编写规范与 CI/CD 实战 本文是 ralph claude人工智能AI 应用自主智能体CLI开发工具Milvus 集成测试框架实战指南基于 MiniClusterV3 的端到端测试编写与运行Milvus 集成测试框架实战指南基于 MiniClusterV3 的端到端测试编写与运行 本文基于 Milvus 仓库的 tests/integration数据库向量数据库分布式数据库后端上一篇Jet Bridge团队权限管理完整指南如何设置安全的多用户协作环境下一篇用NCU剖析FlashKDA从kernel耗时到warp stall的完整流程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考