TiDB 开源仓库 CI 流水线触发命令完全指南从 PR 自动检查到手动集成测试【免费下载链接】tidbTiDB is built for agentic workloads that grow unpredictably, with ACID guarantees and native support for transactions, analytics, and vector search. No data silos. No noisy neighbors. No infrastructure ceiling.项目地址: https://gitcode.com/GitHub_Trending/ti/tidb导读TiDB 作为一个包含内核pkg/、备份恢复br/、数据导入lightning/与导出dumpling/等多个子系统的巨型 Go 仓库其质量保障依赖一套分层明确的 CI持续集成流水线。本文以仓库根目录的 ci.md 为核心系统梳理在 TiDB 开源贡献流程中如何触发各条 CI 流水线哪些任务随 PR/推送自动执行哪些高成本集成测试需要手动触发以及/test ?命令的用法。读完本文你将能够像维护者一样通过 PR 评论区的一条命令精准调度构建、代码检查、单元测试与各种基于真实 TiKV 的集成测试为你的 PR 获得完整质量背书。一、TiDB 的 CI 触发机制总览在 TiDB 仓库中CI 的执行入口是一个 Jenkins 流水线其定义位于仓库根目录的 Jenkinsfile内容极为精简#!groovy node { def TIDB_TEST_BRANCH master def TIKV_BRANCH master def PD_BRANCH master fileLoader.withGit(gitgithub.com:pingcap/SRE.git, master, github-iamxy-ssh, ) { fileLoader.load(jenkins/ci/pingcap_tidb_branch.groovy).call(TIDB_TEST_BRANCH, TIKV_BRANCH, PD_BRANCH) } }从源码结构看TiDB 实际的 CI 任务定义各 pipeline 对应的test/verify目录保存在独立的运维仓库中本仓库仅声明了被测代码分支与所依赖的 TiKV、PD 测试分支版本。理解这一点对贡献者很有用CI 并非完全跑在本仓库代码内还包括了外部tidb-test、tikv、pd等配套仓库的协作测试。1.1 自动触发 vs 手动触发在 PR 中直接输入/test ?即可列出当前仓库支持的全部 CI 触发命令。整体上 CI 分为两类Auto Trigger Yes当你提交一个 PR 或向已有 PR 推送新提交时流水线会自动触发无需任何操作Auto Trigger No通常是比较耗时、需要完整分布式环境的集成测试必须由维护者在 PR 评论区手动输入/test xxx才会运行用于在合并前给 PR 质量加一道保险。二、自动触发的质量门禁流水线以下流水线在任何 PR/推送时自动执行构成 TiDB 的第一道质量防线。2.1/test build—— 编译产物验证属性内容触发命令/test build验证内容编译所有二进制Build binaries自动触发是TiDB 仓库包含多个可执行组件均通过根目录 Makefile 组织构建。本地对应的目标包括make server—— 编译cmd/tidb-server得到bin/tidb-server对应 cmd/tidb-server/main.gomake build_br—— 编译备份恢复工具入口在 br/cmd/brmake build_lightning/make build_lightning-ctl—— 编译 TiDB Lightning 及其控制工具入口在 lightning/cmdmake buildsucc—— 空目标用于串联确认构建成功。构建参数集中在 Makefile.common例如通过BUILD_TAGS注入版本信息、通过LDFLAGS写入TiDBReleaseVersion、TiDBGitHash等。该流水线相当于在干净环境里对所有make目标做一次冒烟编译防止合并的代码破坏任一组件的可构建性。2.2/test check-dev—— 常用代码质量检查属性内容触发命令/test check-dev验证内容常用检查任务包含lint、tidy等自动触发是check-dev对应本地make check/make dev所覆盖的常规静态检查在 Makefile 中可以观察到其核心依赖链lint使用 revive 与 golangci-lint 对FILES_TIDB_TESTS即除br/、cmd/、dumpling/之外的包做风格与静态分析并用tools/dashboard-linter校验pkg/metrics/grafana/下的监控面板 JSONtidy执行./tools/check/check-tidy.sh确保go.mod与go.sum保持一致check-parallel强制 Go 测试串行执行禁止出现t.Parallel()见 MakefiletestSuite、errdoc、license、check-bazel-prepare分别校验TestSuite命名规范、errors.toml错误码文档、文件许可证头与 Bazel 构建文件是否同步更新。2.3/test check-dev2—— 基于真实 TiKV 的全量测试属性内容触发命令/test check-dev2验证内容tests/realtikvtest下的全部 realtikv 测试自动触发是tests/realtikvtest是 TiDB 中需要真实 TiKV/PD 集群才能运行的测试套件集合。从目录结构看见 tests/realtikvtest它按功能域划分为众多子套件例如addindextest/addindextest4/ADD INDEX 回填相关ddltest/、flashbacktest/、pessimistictest/、pipelineddmltest/importintotest/importintotest4/IMPORT INTO 相关pushdowntest/、sessiontest/、startertest/、statisticstest/、txntest/。其启动与执行方式记录在 tests/realtikvtest/scripts/classic/README.md脚本会拉起 3 个 PD 节点与 3 个 TiKV 服务器占用 PD 端口2379/2380/2381/2383/2384与 TiKV 端口20160-20162/20180-20182随后以./run-tests-with-gotest.sh test_suite [timeout] # 例如 ./run-tests-with-gotest.sh addindextest 60m ./run-tests.sh make_test_task # 例如 ./run-tests.sh bazel_addindextest的方式执行单个套件。check-dev2本质上把上述所有 realtikv 套件一次性跑完因此任何改动如果影响了真实 KV 存储上的事务、DDL、统计信息等路径都会在此暴露问题。2.4/test mysql-test与/test pull-mysql-client-test—— MySQL 兼容性测试属性内容触发命令/test mysql-test验证内容PingCAP-QE/tidb-testmysql_test中的全部 MySQL 测试自动触发是触发命令/test pull-mysql-client-test验证内容PingCAP-QE/tidb-test 中的 MySQL 客户端测试自动触发是TiDB 的核心定位之一是高度兼容 MySQL 协议与语义。这两条流水线引用了外部测试仓库PingCAP-QE/tidb-test中的mysql_test用例集mysql-test直接运行这些用例而pull-mysql-client-test侧重各类 MySQL 客户端的连接行为验证。2.5/test unit-test—— 全量单元测试属性内容触发命令/test unit-test验证内容全部单元测试自动触发是本地与 CI 单测对应的 Makefile 目标包括utMakefile与gotest_in_verify_ciMakefile。CI 场景使用tools/bin/ut源码见 tools/check/ut.go它先启用 failpoint./tools/check/failpoint-state.sh enable go与注入测试专用LDFLAGS如config.checkBeforeDropLDFlag1见 Makefile.common支持--junitfile、--coverprofile生成 CI 报告支持--except/--only结合unstable.txt把不稳定用例单独分组避免偶发失败阻塞主干。从 Makefile.common 可以看出单测默认携带deadlock,intest构建标签意味着部分测试代码仅在测试构建中存在intest并在启用 deadlock 检测的条件下运行。2.6/test pull-integration-ddl-test—— 外部 DDL 回归集属性内容触发命令/test pull-integration-ddl-test验证内容PingCAP-QE/tidb-testddl_test中的全部 DDL 测试自动触发是DDL 是 TiDB 正确性与稳定性要求最高的子系统之一本仓库的 DDL 实现位于 pkg/ddl包含 online DDL、backfill、dist reorg 等大量逻辑。除仓库内部 pkg/ddl 与 tests/realtikvtest/ddltest 的测试外该流水线还拉取外部tidb-test仓库的ddl_test用例对 ALTER TABLE、索引构建等历史回归场景做交叉验证。三、手动触发的深度集成测试流水线以下流水线默认不自动运行需要维护者在 PR 评论区显式输入命令通常作为合并前的最终把关。3.1/test pull-br-integration-test与/test pull-lightning-integration-test—— 备份恢复与数据导入属性内容触发命令/test pull-br-integration-test验证内容br/tests中的全部 BR 集成测试自动触发否触发命令/test pull-lightning-integration-test验证内容br/tests中的全部 Lightning 集成测试自动触发否BRBackup Restore与 TiDB Lightning 的集成测试分别位于 br/testsBR 用例与 lightning/testsLightning 用例。注意 ci.md 中 Lightning 一行标注的测试目录同样是br/tests这是仓库演进过程中 Lightning 一度内嵌于 br 目录参见br/pkg/与 lightning/pkg 结构留下的组织痕迹。两套测试都依赖make build_br/make build_lightning先产出二进制再通过make br_integration_test、make lightning_integration_test等目标见 Makefile拉起真实集群执行端到端备份/导入/恢复验证。3.2/test pull-common-test与/test pull-integration-common-test—— ORM 生态兼容属性内容触发命令/test pull-common-test验证内容通过 unistore 执行的若干 ORM 测试自动触发否触发命令/test pull-integration-common-test验证内容通过 tikv 执行的若干 ORM 测试自动触发否这两条流水线验证各类 ORM对象关系映射框架在 TiDB 上的兼容性区别在于底层存储引擎pull-common-test走 unistore纯 Go 实现的嵌入式 KV无外部依赖运行快pull-integration-common-test走真实 TiKV覆盖真实事务/锁语义下的行为。当你的改动涉及事务隔离级别、连接会话行为或 DML 路径时这两条流水线能有效发现仅在真实引擎下复现的 ORM 兼容问题。3.3/test pull-e2e-test—— 进程级端到端测试属性内容触发命令/test pull-e2e-test验证内容tests/globalkilltest与tests/graceshutdown中的 E2E 测试自动触发否E2E 测试关注的是多进程/多节点场景下的行为典型代表是 tests/globalkilltest“Global Kill” 全局 Kill 功能验证与tests/graceshutdown优雅停机。以 tests/globalkilltest/README.md 为例它通过重新编译 TiDB 二进制并注入更短的超时参数--conn_lost、--conn_restored将原本需要数小时的“PD 失联后 Kill 连接”场景压缩到可自动验证的窗口内覆盖 CtrlC / KILL 语句、多 TiDB 节点、PD 断连恢复后连接可再被 Kill 等 7 类场景。运行方式cd tests/globalkilltest make ./run-tests.sh # 或单独跑某个用例 go test -check.f TestMultipleTiDB -args --pd127.0.0.1:23793.4/test pull-integration-copr-test—— Coprocessor 一致性测试属性内容触发命令/test pull-integration-copr-test验证内容tikv/copr-test 中的 Coprocessor 测试自动触发否TiDB 会将下推算子如聚合、表达式计算发送到 TiKV 的 Coprocessor 执行。为了验证“下推结果与 TiDB 本地计算结果一致”该流水线引用 TiKV 配套的 copr-test 用例集做结果比对是保障下推正确性的关键防线。3.5 客户端生态流水线pull-integration-nodejs-test/pull-integration-jdbc-test/pull-integration-mysql-test属性内容触发命令/test pull-integration-nodejs-test验证内容PingCAP-QE/tidb-test 中的 Node.js ORM 测试自动触发否触发命令/test pull-integration-jdbc-test验证内容PingCAP-QE/tidb-test 中的全部 JDBC 测试自动触发否触发命令/test pull-integration-mysql-test验证内容通过 tikv 执行 PingCAP-QE/tidb-test 的全部 mysql 测试自动触发否这三条流水线专门验证驱动程序与协议栈兼容性pull-integration-jdbc-test覆盖 Java JDBC对数据类型、元数据、预处理语句的兼容性最敏感pull-integration-nodejs-test覆盖 Node.js 生态pull-integration-mysql-test则把 2.4 节的mysql_test换到真实 TiKV 上再跑一遍用于排查仅在真实引擎下出现的协议/行为差异。3.6/test pull-sqllogic-test—— 逻辑一致性回归属性内容触发命令/test pull-sqllogic-test验证内容PingCAP-QE/tidb-test 中的 SQL logic 测试自动触发否SQL logic 测试是业界经典的“用海量随机/确定性 SQL 语句比对多个数据库执行结果”的回归手段。本仓库内的对应测试框架位于 tests/integrationtest通过make integrationtest以.test.result文件驱动的 SQL 执行结果比对见 Makefile而pull-sqllogic-test则引入外部更大规模的 sqllogic 用例集用于发现优化器改写、表达式求值等层面的语义偏差。3.7/test pull-tiflash-test—— TiFlash 列存协同测试属性内容触发命令/test pull-tiflash-test验证内容pingcap/tiflashtests/docker/中的 TiFlash 测试自动触发否当改动涉及 TiFlash 相关的 MPP 执行、列存读取或tiflash副本调度时TiDB 侧对 TiFlash 副本的管理可参考 pkg/ddl/ddl_tiflash_api.go需要通过该流水线启动 docker 化的 TiFlash 集群做完整协同验证。四、全量流水线速查表为便于日常对照以下汇总 ci.md 中全部 19 条流水线可直接复制使用ci 流水线命令验证内容自动触发build/test build编译所有二进制是check-dev/test check-dev常见检查lint、tidy 等是check-dev2/test check-dev2tests/realtikvtest下全部 realtikv 测试是mysql-test/test mysql-testPingCAP-QE/tidb-testmysql_test是unit-test/test unit-test全部单元测试是pull-integration-ddl-test/test pull-integration-ddl-testPingCAP-QE/tidb-testddl_test是pull-mysql-client-test/test pull-mysql-client-testMySQL 客户端测试是pull-br-integration-test/test pull-br-integration-testbr/tests全部 BR 集成测试否pull-lightning-integration-test/test pull-lightning-integration-testbr/tests全部 Lightning 集成测试否pull-common-test/test pull-common-test基于 unistore 的 ORM 测试否pull-e2e-test/test pull-e2e-testtests/globalkilltest与tests/graceshutdown的 E2E 测试否pull-integration-common-test/test pull-integration-common-test基于 tikv 的 ORM 测试否pull-integration-copr-test/test pull-integration-copr-testtikv/copr-test 的 Coprocessor 测试否pull-integration-nodejs-test/test pull-integration-nodejs-testNode.js ORM 测试否pull-integration-jdbc-test/test pull-integration-jdbc-test全部 JDBC 测试否pull-integration-mysql-test/test pull-integration-mysql-test基于 tikv 的全部 mysql 测试否pull-sqllogic-test/test pull-sqllogic-testSQL logic 测试否pull-tiflash-test/test pull-tiflash-testTiFlash 测试否五、贡献者实操建议结合以上触发机制给 TiDB 贡献者三条实用建议善用自动门禁快速迭代提交后重点观察build、check-dev、unit-test、mysql-test与check-dev2五条自动流水线。其中check-devlint/tidy失败通常意味着需要本地先跑make check或make fmtcheck-dev2失败则意味着改动影响了真实 TiKV 上的行为可参照 tests/realtikvtest/scripts/classic/README.md 在本地拉起集群复现。按改动范围主动申请手动流水线手动流水线并非每 PR 必跑而是“按需”。如果你的改动涉及备份/恢复工具链请维护者执行/test pull-br-integration-test涉及导入则执行/test pull-lightning-integration-test改动事务/会话语义时可请求/test pull-integration-common-test、/test pull-e2e-test与pull-integration-jdbc-test改动下推逻辑则请求/test pull-integration-copr-test涉及 SQL 语义则可请求/test pull-sqllogic-test。不确定时先查后问所有可用命令以/test ?输出的实时列表为准——它由仓库当前配置动态生成比任何静态文档都更权威同时留意 Jenkinsfile 中声明的测试分支TIDB_TEST_BRANCH、TIKV_BRANCH、PD_BRANCH部分外部用例集与 TiDB master 存在版本耦合属正常现象。小结TiDB 的 CI 体系呈“自动门禁 手动深测”双层结构——自动层覆盖构建、静态检查、单元测试、MySQL 兼容与真实 TiKV 基础测试保证主干不被低级问题污染手动层则按改动领域精准调度 BR/Lightning、ORM、Coprocessor、E2E、sqllogic、TiFlash 等高成本集成测试为合并质量提供最终保障。对贡献者而言掌握/test pipeline命令与各流水线的适用范围是让 PR 快速通过评审、进入合并队列的必备技能。【免费下载链接】tidbTiDB is built for agentic workloads that grow unpredictably, with ACID guarantees and native support for transactions, analytics, and vector search. No data silos. No noisy neighbors. No infrastructure ceiling.项目地址: https://gitcode.com/GitHub_Trending/ti/tidb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 TiDB 开源仓库 CI 流水线触发命令完全指南：从 PR 自动检查到手动集成测试
TiDB 开源仓库 CI 流水线触发命令完全指南从 PR 自动检查到手动集成测试【免费下载链接】tidbTiDB is built for agentic workloads that grow unpredictably, with ACID guarantees and native support for transactions, analytics, and vector search. No data silos. No noisy neighbors. No infrastructure ceiling.项目地址: https://gitcode.com/GitHub_Trending/ti/tidb导读TiDB 作为一个包含内核pkg/、备份恢复br/、数据导入lightning/与导出dumpling/等多个子系统的巨型 Go 仓库其质量保障依赖一套分层明确的 CI持续集成流水线。本文以仓库根目录的 ci.md 为核心系统梳理在 TiDB 开源贡献流程中如何触发各条 CI 流水线哪些任务随 PR/推送自动执行哪些高成本集成测试需要手动触发以及/test ?命令的用法。读完本文你将能够像维护者一样通过 PR 评论区的一条命令精准调度构建、代码检查、单元测试与各种基于真实 TiKV 的集成测试为你的 PR 获得完整质量背书。一、TiDB 的 CI 触发机制总览在 TiDB 仓库中CI 的执行入口是一个 Jenkins 流水线其定义位于仓库根目录的 Jenkinsfile内容极为精简#!groovy node { def TIDB_TEST_BRANCH master def TIKV_BRANCH master def PD_BRANCH master fileLoader.withGit(gitgithub.com:pingcap/SRE.git, master, github-iamxy-ssh, ) { fileLoader.load(jenkins/ci/pingcap_tidb_branch.groovy).call(TIDB_TEST_BRANCH, TIKV_BRANCH, PD_BRANCH) } }从源码结构看TiDB 实际的 CI 任务定义各 pipeline 对应的test/verify目录保存在独立的运维仓库中本仓库仅声明了被测代码分支与所依赖的 TiKV、PD 测试分支版本。理解这一点对贡献者很有用CI 并非完全跑在本仓库代码内还包括了外部tidb-test、tikv、pd等配套仓库的协作测试。1.1 自动触发 vs 手动触发在 PR 中直接输入/test ?即可列出当前仓库支持的全部 CI 触发命令。整体上 CI 分为两类Auto Trigger Yes当你提交一个 PR 或向已有 PR 推送新提交时流水线会自动触发无需任何操作Auto Trigger No通常是比较耗时、需要完整分布式环境的集成测试必须由维护者在 PR 评论区手动输入/test xxx才会运行用于在合并前给 PR 质量加一道保险。二、自动触发的质量门禁流水线以下流水线在任何 PR/推送时自动执行构成 TiDB 的第一道质量防线。2.1/test build—— 编译产物验证属性内容触发命令/test build验证内容编译所有二进制Build binaries自动触发是TiDB 仓库包含多个可执行组件均通过根目录 Makefile 组织构建。本地对应的目标包括make server—— 编译cmd/tidb-server得到bin/tidb-server对应 cmd/tidb-server/main.gomake build_br—— 编译备份恢复工具入口在 br/cmd/brmake build_lightning/make build_lightning-ctl—— 编译 TiDB Lightning 及其控制工具入口在 lightning/cmdmake buildsucc—— 空目标用于串联确认构建成功。构建参数集中在 Makefile.common例如通过BUILD_TAGS注入版本信息、通过LDFLAGS写入TiDBReleaseVersion、TiDBGitHash等。该流水线相当于在干净环境里对所有make目标做一次冒烟编译防止合并的代码破坏任一组件的可构建性。2.2/test check-dev—— 常用代码质量检查属性内容触发命令/test check-dev验证内容常用检查任务包含lint、tidy等自动触发是check-dev对应本地make check/make dev所覆盖的常规静态检查在 Makefile 中可以观察到其核心依赖链lint使用 revive 与 golangci-lint 对FILES_TIDB_TESTS即除br/、cmd/、dumpling/之外的包做风格与静态分析并用tools/dashboard-linter校验pkg/metrics/grafana/下的监控面板 JSONtidy执行./tools/check/check-tidy.sh确保go.mod与go.sum保持一致check-parallel强制 Go 测试串行执行禁止出现t.Parallel()见 MakefiletestSuite、errdoc、license、check-bazel-prepare分别校验TestSuite命名规范、errors.toml错误码文档、文件许可证头与 Bazel 构建文件是否同步更新。2.3/test check-dev2—— 基于真实 TiKV 的全量测试属性内容触发命令/test check-dev2验证内容tests/realtikvtest下的全部 realtikv 测试自动触发是tests/realtikvtest是 TiDB 中需要真实 TiKV/PD 集群才能运行的测试套件集合。从目录结构看见 tests/realtikvtest它按功能域划分为众多子套件例如addindextest/addindextest4/ADD INDEX 回填相关ddltest/、flashbacktest/、pessimistictest/、pipelineddmltest/importintotest/importintotest4/IMPORT INTO 相关pushdowntest/、sessiontest/、startertest/、statisticstest/、txntest/。其启动与执行方式记录在 tests/realtikvtest/scripts/classic/README.md脚本会拉起 3 个 PD 节点与 3 个 TiKV 服务器占用 PD 端口2379/2380/2381/2383/2384与 TiKV 端口20160-20162/20180-20182随后以./run-tests-with-gotest.sh test_suite [timeout] # 例如 ./run-tests-with-gotest.sh addindextest 60m ./run-tests.sh make_test_task # 例如 ./run-tests.sh bazel_addindextest的方式执行单个套件。check-dev2本质上把上述所有 realtikv 套件一次性跑完因此任何改动如果影响了真实 KV 存储上的事务、DDL、统计信息等路径都会在此暴露问题。2.4/test mysql-test与/test pull-mysql-client-test—— MySQL 兼容性测试属性内容触发命令/test mysql-test验证内容PingCAP-QE/tidb-testmysql_test中的全部 MySQL 测试自动触发是触发命令/test pull-mysql-client-test验证内容PingCAP-QE/tidb-test 中的 MySQL 客户端测试自动触发是TiDB 的核心定位之一是高度兼容 MySQL 协议与语义。这两条流水线引用了外部测试仓库PingCAP-QE/tidb-test中的mysql_test用例集mysql-test直接运行这些用例而pull-mysql-client-test侧重各类 MySQL 客户端的连接行为验证。2.5/test unit-test—— 全量单元测试属性内容触发命令/test unit-test验证内容全部单元测试自动触发是本地与 CI 单测对应的 Makefile 目标包括utMakefile与gotest_in_verify_ciMakefile。CI 场景使用tools/bin/ut源码见 tools/check/ut.go它先启用 failpoint./tools/check/failpoint-state.sh enable go与注入测试专用LDFLAGS如config.checkBeforeDropLDFlag1见 Makefile.common支持--junitfile、--coverprofile生成 CI 报告支持--except/--only结合unstable.txt把不稳定用例单独分组避免偶发失败阻塞主干。从 Makefile.common 可以看出单测默认携带deadlock,intest构建标签意味着部分测试代码仅在测试构建中存在intest并在启用 deadlock 检测的条件下运行。2.6/test pull-integration-ddl-test—— 外部 DDL 回归集属性内容触发命令/test pull-integration-ddl-test验证内容PingCAP-QE/tidb-testddl_test中的全部 DDL 测试自动触发是DDL 是 TiDB 正确性与稳定性要求最高的子系统之一本仓库的 DDL 实现位于 pkg/ddl包含 online DDL、backfill、dist reorg 等大量逻辑。除仓库内部 pkg/ddl 与 tests/realtikvtest/ddltest 的测试外该流水线还拉取外部tidb-test仓库的ddl_test用例对 ALTER TABLE、索引构建等历史回归场景做交叉验证。三、手动触发的深度集成测试流水线以下流水线默认不自动运行需要维护者在 PR 评论区显式输入命令通常作为合并前的最终把关。3.1/test pull-br-integration-test与/test pull-lightning-integration-test—— 备份恢复与数据导入属性内容触发命令/test pull-br-integration-test验证内容br/tests中的全部 BR 集成测试自动触发否触发命令/test pull-lightning-integration-test验证内容br/tests中的全部 Lightning 集成测试自动触发否BRBackup Restore与 TiDB Lightning 的集成测试分别位于 br/testsBR 用例与 lightning/testsLightning 用例。注意 ci.md 中 Lightning 一行标注的测试目录同样是br/tests这是仓库演进过程中 Lightning 一度内嵌于 br 目录参见br/pkg/与 lightning/pkg 结构留下的组织痕迹。两套测试都依赖make build_br/make build_lightning先产出二进制再通过make br_integration_test、make lightning_integration_test等目标见 Makefile拉起真实集群执行端到端备份/导入/恢复验证。3.2/test pull-common-test与/test pull-integration-common-test—— ORM 生态兼容属性内容触发命令/test pull-common-test验证内容通过 unistore 执行的若干 ORM 测试自动触发否触发命令/test pull-integration-common-test验证内容通过 tikv 执行的若干 ORM 测试自动触发否这两条流水线验证各类 ORM对象关系映射框架在 TiDB 上的兼容性区别在于底层存储引擎pull-common-test走 unistore纯 Go 实现的嵌入式 KV无外部依赖运行快pull-integration-common-test走真实 TiKV覆盖真实事务/锁语义下的行为。当你的改动涉及事务隔离级别、连接会话行为或 DML 路径时这两条流水线能有效发现仅在真实引擎下复现的 ORM 兼容问题。3.3/test pull-e2e-test—— 进程级端到端测试属性内容触发命令/test pull-e2e-test验证内容tests/globalkilltest与tests/graceshutdown中的 E2E 测试自动触发否E2E 测试关注的是多进程/多节点场景下的行为典型代表是 tests/globalkilltest“Global Kill” 全局 Kill 功能验证与tests/graceshutdown优雅停机。以 tests/globalkilltest/README.md 为例它通过重新编译 TiDB 二进制并注入更短的超时参数--conn_lost、--conn_restored将原本需要数小时的“PD 失联后 Kill 连接”场景压缩到可自动验证的窗口内覆盖 CtrlC / KILL 语句、多 TiDB 节点、PD 断连恢复后连接可再被 Kill 等 7 类场景。运行方式cd tests/globalkilltest make ./run-tests.sh # 或单独跑某个用例 go test -check.f TestMultipleTiDB -args --pd127.0.0.1:23793.4/test pull-integration-copr-test—— Coprocessor 一致性测试属性内容触发命令/test pull-integration-copr-test验证内容tikv/copr-test 中的 Coprocessor 测试自动触发否TiDB 会将下推算子如聚合、表达式计算发送到 TiKV 的 Coprocessor 执行。为了验证“下推结果与 TiDB 本地计算结果一致”该流水线引用 TiKV 配套的 copr-test 用例集做结果比对是保障下推正确性的关键防线。3.5 客户端生态流水线pull-integration-nodejs-test/pull-integration-jdbc-test/pull-integration-mysql-test属性内容触发命令/test pull-integration-nodejs-test验证内容PingCAP-QE/tidb-test 中的 Node.js ORM 测试自动触发否触发命令/test pull-integration-jdbc-test验证内容PingCAP-QE/tidb-test 中的全部 JDBC 测试自动触发否触发命令/test pull-integration-mysql-test验证内容通过 tikv 执行 PingCAP-QE/tidb-test 的全部 mysql 测试自动触发否这三条流水线专门验证驱动程序与协议栈兼容性pull-integration-jdbc-test覆盖 Java JDBC对数据类型、元数据、预处理语句的兼容性最敏感pull-integration-nodejs-test覆盖 Node.js 生态pull-integration-mysql-test则把 2.4 节的mysql_test换到真实 TiKV 上再跑一遍用于排查仅在真实引擎下出现的协议/行为差异。3.6/test pull-sqllogic-test—— 逻辑一致性回归属性内容触发命令/test pull-sqllogic-test验证内容PingCAP-QE/tidb-test 中的 SQL logic 测试自动触发否SQL logic 测试是业界经典的“用海量随机/确定性 SQL 语句比对多个数据库执行结果”的回归手段。本仓库内的对应测试框架位于 tests/integrationtest通过make integrationtest以.test.result文件驱动的 SQL 执行结果比对见 Makefile而pull-sqllogic-test则引入外部更大规模的 sqllogic 用例集用于发现优化器改写、表达式求值等层面的语义偏差。3.7/test pull-tiflash-test—— TiFlash 列存协同测试属性内容触发命令/test pull-tiflash-test验证内容pingcap/tiflashtests/docker/中的 TiFlash 测试自动触发否当改动涉及 TiFlash 相关的 MPP 执行、列存读取或tiflash副本调度时TiDB 侧对 TiFlash 副本的管理可参考 pkg/ddl/ddl_tiflash_api.go需要通过该流水线启动 docker 化的 TiFlash 集群做完整协同验证。四、全量流水线速查表为便于日常对照以下汇总 ci.md 中全部 19 条流水线可直接复制使用ci 流水线命令验证内容自动触发build/test build编译所有二进制是check-dev/test check-dev常见检查lint、tidy 等是check-dev2/test check-dev2tests/realtikvtest下全部 realtikv 测试是mysql-test/test mysql-testPingCAP-QE/tidb-testmysql_test是unit-test/test unit-test全部单元测试是pull-integration-ddl-test/test pull-integration-ddl-testPingCAP-QE/tidb-testddl_test是pull-mysql-client-test/test pull-mysql-client-testMySQL 客户端测试是pull-br-integration-test/test pull-br-integration-testbr/tests全部 BR 集成测试否pull-lightning-integration-test/test pull-lightning-integration-testbr/tests全部 Lightning 集成测试否pull-common-test/test pull-common-test基于 unistore 的 ORM 测试否pull-e2e-test/test pull-e2e-testtests/globalkilltest与tests/graceshutdown的 E2E 测试否pull-integration-common-test/test pull-integration-common-test基于 tikv 的 ORM 测试否pull-integration-copr-test/test pull-integration-copr-testtikv/copr-test 的 Coprocessor 测试否pull-integration-nodejs-test/test pull-integration-nodejs-testNode.js ORM 测试否pull-integration-jdbc-test/test pull-integration-jdbc-test全部 JDBC 测试否pull-integration-mysql-test/test pull-integration-mysql-test基于 tikv 的全部 mysql 测试否pull-sqllogic-test/test pull-sqllogic-testSQL logic 测试否pull-tiflash-test/test pull-tiflash-testTiFlash 测试否五、贡献者实操建议结合以上触发机制给 TiDB 贡献者三条实用建议善用自动门禁快速迭代提交后重点观察build、check-dev、unit-test、mysql-test与check-dev2五条自动流水线。其中check-devlint/tidy失败通常意味着需要本地先跑make check或make fmtcheck-dev2失败则意味着改动影响了真实 TiKV 上的行为可参照 tests/realtikvtest/scripts/classic/README.md 在本地拉起集群复现。按改动范围主动申请手动流水线手动流水线并非每 PR 必跑而是“按需”。如果你的改动涉及备份/恢复工具链请维护者执行/test pull-br-integration-test涉及导入则执行/test pull-lightning-integration-test改动事务/会话语义时可请求/test pull-integration-common-test、/test pull-e2e-test与pull-integration-jdbc-test改动下推逻辑则请求/test pull-integration-copr-test涉及 SQL 语义则可请求/test pull-sqllogic-test。不确定时先查后问所有可用命令以/test ?输出的实时列表为准——它由仓库当前配置动态生成比任何静态文档都更权威同时留意 Jenkinsfile 中声明的测试分支TIDB_TEST_BRANCH、TIKV_BRANCH、PD_BRANCH部分外部用例集与 TiDB master 存在版本耦合属正常现象。小结TiDB 的 CI 体系呈“自动门禁 手动深测”双层结构——自动层覆盖构建、静态检查、单元测试、MySQL 兼容与真实 TiKV 基础测试保证主干不被低级问题污染手动层则按改动领域精准调度 BR/Lightning、ORM、Coprocessor、E2E、sqllogic、TiFlash 等高成本集成测试为合并质量提供最终保障。对贡献者而言掌握/test pipeline命令与各流水线的适用范围是让 PR 快速通过评审、进入合并队列的必备技能。【免费下载链接】tidbTiDB is built for agentic workloads that grow unpredictably, with ACID guarantees and native support for transactions, analytics, and vector search. No data silos. No noisy neighbors. No infrastructure ceiling.项目地址: https://gitcode.com/GitHub_Trending/ti/tidb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考