T3 Code CI质量门槛全解typecheck、lint、test如何在PR上层层把关完整指南【免费下载链接】t3code项目地址: https://gitcode.com/GitHub_Trending/t3/t3codeT3 Code 是一个开源的Agent 驾驶舱让你通过手机、Web 和桌面端远程控制本机的 Claude、Codex、Cursor 等编码 Agent。它的代码质量完全交给一套严格的 CI 流水线每一次 Pull RequestPR都要依次闯过Check格式 lint typecheck、Test全仓测试、Rust 检查、移动端静态分析和Release Smoke五道关卡全部绿灯才能合入。本文将带你逐层拆解这套 CI 质量门槛是如何工作的。T3 Code 是什么先看产品全貌对新手来说可以先直观认识一下这个项目。下图是 T3 Code 桌面端的运行界面左侧是项目与任务列表右侧是 Agent 的执行过程与代码变更底部是发送指令的输入框。而下图展示了 Agent 完成一轮修改后的代码总览变更文件树、逐文件的增删行数31/-17以及 View diff 入口——这正是 CI 中各个质量门槛最终守护的对象。CI 总入口ci.yml 的触发时机与全局约定整条质量流水线定义在 ci.yml 中触发条件有两个任何PR提交pull_request推送到main 分支push两个值得注意的工程细节并发去重同一 PR 的多次提交会复用同一个并发组ci-${PR编号}旧运行会被自动取消避免排队浪费。精简检出所有 Job 都使用 sparse-checkout 排除.repos/目录减少无关文件的检出开销。官方文档对这套门槛有简洁的总结可参考 docs/internals/ci.md。第一道关Check —— 格式化、lint 与 typecheckCheck Job 是 PR 的第一道过滤网运行在 8 核 Linux 上限时的 10 分钟内要完成以下动作见 ci.yml#L45-L58步骤命令作用安装依赖vpVite 工具链基于根package.json锁定 Node 版本并安装准备 Electronvp run --filter t3tools/desktop ensure:electron下载桌面端所需的 Electron 运行时格式 lintvp check格式化检查与 lint 规则校验类型检查vpr typecheck整个 monorepo 的类型检查构建桌面端vp run build:desktop提前暴露构建问题校验 preload 包node apps/desktop/scripts/verify-preload-bundle.mjs确保 Electron 沙箱可以安全加载 preload 脚本其中 lint 规则集中在根目录的 vite.config.ts它启用了 eslint、oxc、react、unicorn、typescript 五类插件还挂载了项目自研的 oxlint-plugin-t3code/ 规则包包含 6 条业务自定义规则例如t3code/no-global-process-runtime禁止全局 process 运行时、t3code/namespace-node-imports规范 Node 导入方式。类型检查则单独由vpr typecheck承担与 lint 解耦——这种分工让每类问题的反馈更聚焦。第二道关Test —— 全仓测试 Server 分片并行测试被拆成两个 Job各有讲究Test Job运行vp run --parallel --filter !t3 test覆盖除apps/server之外的全部 workspace并行度限制为 4让各包测试在 runner 上同时跑。Test Server Jobapps/server开启了严格的单文件串行模式fileParallelism: false239 个测试文件如果串行会太慢所以 CI 用--shard 1/3、2/3、3/3把它切成3 个分片分到 3 台独立 runner 上跑既保住隔离性又压缩总时长。Server 测试还有一个彩蛋某个测试文件会生成线程迁移传输预算报告Transfer Budget ReportCI 检测到报告后会自动追加到 Job Summary 并上传为 artifact方便维护者跨 PR 观察性能预算的变化。第三道关Rust 与移动端原生静态分析这个项目并非纯 TypeScript还有两处容易被忽略的原生代码Rust Job对 native/resource-monitor/ 执行cargo fmt --check和cargo test --locked。它被单独拆出来是因为在 Check/Test 的关键路径上装 Rust 工具链每次要多花 7~9 秒。移动端原生检查iOS 的 Swift 与 Android 的 Kotlin 源码需要 SwiftLint / detekt / ktlint 检查而这必须跑在付费约 6.7 倍于 Linux 的 macOS runner上。于是 CI 设计了一个廉价的 Linux 门禁 Jobmobile_native_changes先只查 API 获取 PR 变更文件列表只有当 diff 真正碰到apps/mobile下的 Swift/Kotlin 源文件、lint 配置或 scripts/mobile-native-static-check.ts 时才启动 macOS runner 跑vp run lint:mobile。门禁采用失败即放行检查fail-open策略——只要变更文件列表解析失败或被截断就直接执行 lint宁可多花钱也不漏检。第四道关Release Smoke —— 让发布事故提前暴露在 PR 上最巧妙的一道关是 release_smoke Job它执行 scripts/release-smoke.ts在一个临时目录里复制 workspace 清单文件然后真实演练发布前的脚本流程——批量改写各包版本号、重算 lockfile、推导 nightly 版本号、合并 macOS/Windows 的更新清单。也就是说只会在打 tag 时才跑的发布逻辑每次 PR 都会先彩排一遍发布流程的 bug 能在 PR 阶段就暴露而不是等到正式发布时才炸。外围防线PR Size 标签与 Vouch 机制质量把关不止发生在 CI 内部仓库还用两个辅助 workflow 约束 PR 文化pr-size.yml自动统计 PR 的有效改动行数混合 PR 中排除测试文件打上size:XS到size:XXL六级标签。这呼应了 PR 模板 中的告诫——小而有焦点的 PR 更受欢迎上千行的大 PR 大概率会被拒。pr-vouch.yml为提交人提供担保vouch标签帮助维护者快速判断陌生贡献者的可信度支持/recheck-vouch重新校验。合入之后release.yml 发布流水线当代码带着绿灯合入 main 并打上一个v*.*.*标签后release.yml 会构建 macOSarm64 x64、Linuxx64、Windowsx64三平台的桌面端安装包并发布。签名凭证存在时才自动启用签名macOS 需要 Apple 团队与描述文件Windows 走 Azure Trusted Signing缺少凭证时仍会发布未签名产物保证发布不中断。小结五道门槛的分工一览门槛守护对象核心命令Check格式、lint、类型、桌面端构建vp checkvpr typecheckTest业务逻辑正确性vp run testServer 3 分片Rust原生资源监控模块cargo fmtcargo testMobile NativeSwift/Kotlin 源码质量vp run lint:mobile按需触发Release Smoke发布流程本身release-smoke.ts这套 CI 的设计哲学可以概括为三点检查与测试分离问题定位更快、昂贵资源按需触发macOS runner 只在需要时启动、发布流程前置演练Smoke 让事故左移。对新手而言这也是一个优秀的工程参考如果你的开源项目也想给 PR 加上层层把关的质量门槛T3 Code 的 ci.yml 几乎可以直接抄作业。【免费下载链接】t3code项目地址: https://gitcode.com/GitHub_Trending/t3/t3code创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考