全程可审计原生 GitHub 工作流现有检查仍掌握决定权每个任务的成本清晰可见
十次失败一次的测试,在证明之前都应视为环境问题
共享的托管执行器每次都会分配一台全新且负载各异的机器,而这正是时序敏感的测试最容易出问题的条件。developerz.ai 将你的虚拟机转为按需启动的 GitHub Actions 执行器:只需修改一个 runs-on: 标签,任务就会在你配置规格的硬件上运行,资源上限也由你设定。每个任务仍在运行结束即销毁的全新容器中执行,因此隔离性不依赖于机器本身是否干净。
可预期的硬件
按任务选择执行器规格(2 至 32 vCPU 标签),不必再排查那些实为共享机器资源争用导致的失败。
每个任务使用全新容器
任务在运行结束即销毁的容器中执行,运行之间不保留任何内容,被污染的缓存不会延续到下一次运行。
智能体持续跟踪 PR
检查失败并不意味着停滞:AI 工程团队会持续跟踪该 PR,并在其停止推进时升级上报。
何时暂停并征询你
无法定论的检查会交还给你
对于平台发起的 PR 或依赖机器人的 PR,失败的 GitHub Actions 任务会先重新运行一次,因此不稳定的测试只需一次重跑,无需修改代码。这需要开启 ci.self_fix(默认开启),并授予 App actions: write 权限;未授予该权限的安装不会重跑,而是直接进入修复轮次。如果任务再次失败,会在该分支上运行一轮修复。当失败的检查数量在多轮之间不再下降时,平台会停止继续修复,并将该 PR 升级给你。
查看失败检查的处理方式