如何按 SIG 归属规则编写 Kubernetes e2e 测试并通过 ownership 校验

如何按 SIG 归属规则编写 Kubernetes e2e 测试并通过 ownership 校验【免费下载链接】kubernetesProduction-Grade Container Scheduling and Management项目地址: https://gitcode.com/GitHub_Trending/kuber/kubernetes给 kubernetes 仓库的test/e2e测试套件新增测试用例时用例必须归属且只归属一个 SIG并按规定的目录与声明方式编写否则 merge-blocking 的 presubmit 作业pull-kubernetes-verify会校验失败。本文基于 test/e2e/README.md 中的 ownership 策略和校验脚本 hack/verify-e2e-test-ownership.sh说明测试放在哪里、如何声明归属以及如何在本地运行 ownership 校验并判断结果。test/e2e是作为 Kubernetes 集群客户端运行的 e2e 套件用于 presubmit、periodic 和 postsubmit 作业其中部分是 merge-blocking、部分是 release-blocking它的e2e.test二进制也被 conformance 测试复用见 test/e2e/framework/README.md。测试必须放在哪个目录test/e2e/README.md 给出的策略包含四条要求每个 e2e 测试必须由一个且仅一个 SIG 拥有测试必须位于 sig-owned package 内部路径匹配模式test/e2e/[{subpath}/]{sig}/...。README 中的示例test/e2e/auth—— 全部测试归 sig-auth 所有test/e2e/common/storage—— 集群级与节点级 e2e 测试共用的测试归 sig-node 所有test/e2e/upgrade/apps—— upgrade 测试所用的测试归 sig-apps 所有每个 sig-owned package 应有 OWNERS 文件定义该 SIG 的 approvers 与 labels使用{subpath}结构的包需要imports.go文件导入各子包供 ginkgo 扫描。所以写测试的第一步是判断用例归属哪个 SIG然后把文件放进test/e2e/sig/对应目录共用型测试放到属主 SIG 的子路径下common/storage的例子。一个测试只能有一个属主 SIG策略不允许双重归属。当前test/e2e下带有 OWNERS 文件的包包括apimachinery、apps、architecture、auth、autoscaling、common、dra、feature、framework、instrumentation、invariants、kubectl、network、node、scheduling、storage、windows。选择目录时可查看目标包的 OWNERS 中labels字段确认属主 SIG例如 test/e2e/node/OWNERS 的labels为sig/node。OWNERS 文件新建子包时才需要补往已有 sig 包中加测试时OWNERS 通常已经存在。例如 test/e2e/autoscaling/OWNERS节选approvers: - sig-autoscaling-maintainers reviewers: - sig-autoscaling-maintainers labels: - sig/autoscaling如果为某 SIG 新建一个 subpath 子包则参照上述格式补充该目录的 OWNERSlabels使用sig/名称形式README 给出的 node 包示例中为labels: [sig/node]。OWNERS 同时定义 approvers、emeritus_approvers 与 reviewers用于代码评审时的审批路由。用顶层 SIGDescribe 声明归属ownership 的声明方式是在 sig-owned package 内定义一个顶层SIGDescribe所有测试通过它注册。autoscaling 包在 test/e2e/autoscaling/framework.go 中的真实写法package autoscaling import k8s.io/kubernetes/test/e2e/framework // SIGDescribe annotates the test with the SIG label. var SIGDescribe framework.SIGDescribe(autoscaling)framework.SIGDescribe的参数有约束小写、无空格、不能带sig-或SIG-前缀。ginkgowrapper.go 中用正则^[a-z](-[a-z])*$校验不合法会记录一个 Bug合法时包装函数在ginkgo.Describe的参数前注入WithLabel(sig-sig)把 SIG 标注打进测试。测试文件内的顶层 Describe 使用这个包级变量节选自 horizontal_pod_autoscaling.govar _ SIGDescribe(feature.HPA, Horizontal pod autoscaling (scale resource: CPU), func() { f : framework.NewDefaultFramework(horizontal-pod-autoscaling) ginkgo.It(should scale up on CPU utilization, func(ctx context.Context) { /* ... */ }) })第一个参数是 test/e2e/feature 包中的预定义 feature 变量如feature.HPA为测试打上 feature 标签第二个参数是顶层测试标题NewDefaultFramework的参数是这一组测试在框架中使用的名称。新增一个测试文件时骨架如下。以 autoscaling 包为例包名、feature 变量、标题与 framework 名称是读者需要按自己用例替换的部分package autoscaling import ( context github.com/onsi/ginkgo/v2 k8s.io/kubernetes/test/e2e/feature k8s.io/kubernetes/test/e2e/framework ) var _ SIGDescribe(feature.HPA, My new autoscaling test, func() { f : framework.NewDefaultFramework(my-new-autoscaling-test) ginkgo.It(should do something, func(ctx context.Context) { // 具体测试逻辑 }) })归属由顶层容器决定校验脚本取测试 Describe 文本链中第一个[sig-...]标签作为属主因此顶层必须通过SIGDescribe声明把测试挂到没有 sig 标注的普通顶层 Describe 下会被判为无主测试。带 subpath 的包imports.go测试放在子路径子目录如test/e2e/common/storage时父包需要imports.go以空白导入的方式导入各子包否则 ginkgo 扫描不到。test/e2e/common/imports.go 的真实内容package common import ( // ensure these packages are scanned by ginkgo for e2e tests _ k8s.io/kubernetes/test/e2e/common/network _ k8s.io/kubernetes/test/e2e/common/node _ k8s.io/kubernetes/test/e2e/common/storage )新增子包后记得在这里补一行对应的导入。本地运行 ownership 校验CI 中该策略由 merge-blocking presubmitpull-kubernetes-verify执行它运行 hack/verify-e2e-test-ownership.sh本地等价命令make verify WHATe2e-test-ownership或者直接执行hack/verify-e2e-test-ownership.sh。make verify WHAT...由 hack/make-rules/verify.sh 实现指定WHAT后只运行文件名去前缀匹配的对应 verify 脚本e2e-test-ownership对应hack/verify-e2e-test-ownership.sh。脚本的执行流程见脚本 L56-L68_output/bin/ginkgo不存在时先执行make ginkgo_output/bin/e2e.test不存在时通过hack/make-rules/build.sh test/e2e/e2e.test构建执行${ginkgo} --dry-runtrue ${e2e_test} -- --spec-dump _output/specsummaries.json。--dry-run只做规格注册、不真正跑测试结果写入_output/specsummaries.json用 jq 把每个测试对照 ownership 策略评估生成结果、失败清单与汇总 JSON。运行前提与副作用构建阶段需要 Go 工具链与 make评估阶段需要 jq会在仓库_output/下产生构建产物与specsummaries.json运行期间创建的临时目录在退出时自动清理trap。设置REUSE_BUILD_OUTPUTy可复用已有构建产物跳过重新构建VERBOSE_OUTPUTy会打印中间.jq文件与 shell 命令。脚本实际执行的策略规则脚本内 jq 部分有两条类别级别规则unowned_testFAIL测试顶层 Describe 必须以[sig-foo]标签开头即必须经顶层 SIGDescribe 声明too_many_sigsWARN测试名链中不应出现多个[sig-foo]标签脚本头部注释还列出两条历史规则测试名不得含[k8s.io]、不得使用 KubeDescribe标注 TODO 待 KubeDescribe 从代码库移除后删除当前 jq 规则中未包含它们。判定校验结果脚本先输出测试总数再按策略逐行输出某策略没有失败测试时该行显示 PASS否则显示策略级别与失败测试数。输出中出现以FAIL开头的行即unowned_test存在失败项时脚本打印 FAIL 并以退出码 1 结束全部通过则最后打印PASS。失败的测试会以 JSON 数组打印每项包含测试完整名称testname、失败策略的原因如must start with [sig-foo]以及相关调用所在的文件名与行号line可据此定位。对照两类失败原因unowned_test该测试的顶层 Describe 未经SIGDescribe声明或放在了没有顶层 sig 标注的 Describe 链下——检查测试文件位置与顶层声明too_many_sigsDescribe 链中出现多个 sig 标签通常是测试被嵌套在另一个SIGDescribe之下——该项为 WARN 级别不会导致脚本以非零码退出但应清理掉多余的嵌套。关于 e2e 测试的更多约定test/e2e/README.md末尾指向 kubernetes/community 仓库中的 e2e-tests.md 文档可在 test/e2e/README.md 查看该引用。【免费下载链接】kubernetesProduction-Grade Container Scheduling and Management项目地址: https://gitcode.com/GitHub_Trending/kuber/kubernetes创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考