跳到正文

使用场景

CI 不稳定,通常是因为环境不在你手里

让你的 GitHub Actions 任务跑在自己的机器上:每次都是同一台机器、同样热的缓存、同样的资源,还有一份你能自己去读的日志。

developerz.yml实时
version: 1
budget:
 max_cost_usd: 5
policy:
 require_checks: true
 deny_paths:
 - infra/prod/**
全程可审计原生的 GitHub 工作流你已有的检查依然说了算每个任务的成本都看得见

十次挂一次的测试,在被证明之前都算环境问题

共享的托管 runner 每次给你一台全新的、负载还各不相同的机器,而这恰恰是对时序敏感的测试最容易出幺蛾子的条件。developerz.ai 把你的虚拟机变成按需启动的 GitHub Actions runner:改一个 runs-on: 标签,任务就跑在你自己定规格的硬件上,资源上限也由你设。每个任务依然跑在一个跑完即销毁的全新容器里,所以隔离性不依赖于那台机器本身是否干净。

可预期的硬件

按任务选 runner 规格(2 到 32 vCPU 的标签),不用再去调试那些其实是别人机器争抢导致的失败。

每个任务一个新容器

任务跑在一个跑完即销毁的容器里。运行之间不留任何东西,所以被污染的缓存不会跟着你走。

agent 会盯着这个 PR

一个红色检查不是死路:维护 agent 会跟着这个 PR,并在它不再往前走时升级上报。

深入一层

CI 那一页给出确切的 diff、runner 规格,以及安全模型:令牌有效期、容器生命周期,和 fork PR 的规则。

自托管 CI

让一支 AI 开发者团队开始干活 少维护。

带上你自己的密钥和机器,放一个 .dz/maintainer/maintainer.yml,剩下的交给循环去跑。全程可审计。目前为邀请制。