Cloudflare 将 CI 管道转变为 TypeScript 工作流

Cloudflare 发布了一个 CI SDK，允许开发者使用 TypeScript 而不是 YAML 定义持续集成（CI）管道，并将每个步骤作为持久化的 Cloudflare Workflow 来运行。

这个包（@cloudflare/ci ）面向 Cloudflare Workers 运行时而非 Node.js，并为 Wrangler 等支持 Workers 的打包工具提供了 TypeScript 源代码。

初始集成从 Cloudflare Artifacts（目前仍处于私有测试阶段）读取代码库。这个代码库本身也是新推出的，于 2026 年 8 月初遵循 Apache 2.0 许可发布。一个可运行的管道还集成了工作流、沙箱、容器和持久化对象以及 R2（启用缓存时）。因此，这是一个平台级的方案，而非简单的 CI 替代方案。命令在相互隔离的沙箱容器中运行，其中提供了缓存所依赖的文件系统快照。

公告中写道，“本质上，CI/CD 管道就是一种工作流”。每个阶段都对应一个工作流步骤，因此，它继承了带检查点的执行机制：失败的步骤会在保留状态的情况下重试，而且可以从该步骤重新开始运行，而非重复整个管道。除非管道另有规定，否则各步骤独立启动，因此会并发执行。开发人员将这些独立的检查封装在 Promise.all() 中，可以确保代码检查、测试、类型检查和构建在部署步骤开始前全部完成。

其中的两种机制解决了常见的 CI 痛点。依赖项缓存将安装步骤的结果作为沙箱文件系统的快照存储在 R2 存储桶中，后续步骤可以复用该结果，无需重新安装。Wrangler 配置中新增的 events 字段可以在 cf.artifacts.repo.pushed 事件发生时直接触发工作流，取代了之前的订阅、队列和消费者连接机制。Cloudflare 表示，他们计划添加来自任何版本控制系统的触发器、部署和预览原语，以及对单体存储库（monorepo）的支持。

该代码库规定了两个在生产环境中至关重要的限制。Runner 命令在可重试的工作流步骤中执行。因此，任何具有外部副作用的命令都必须是幂等的，否则重试会导致该命令的副作用加倍。此外，该 SDK 会在 CiRunnerResult.logs 中返回未经机密信息屏蔽处理的原始命令输出。

Cloudflare 将“自愈”功能作为一个单独的示例发布，而非作为包的一个功能。它将管道封装在 try/catch 块中，并在运行器失败时调用应用程序拥有的智能代理。它在 Workers AI 上运行 Think 测试框架，利用 Moonshot 的 Kimi 编码模型提出补丁，将其提交到分支，并在工程师将其合并前保持原始运行的失败状态。该代理及其 AI 依赖项没有包含在 @cloudflare/ci 之中。

Cloudflare 并非首个将管道迁移到通用编程语言的公司。Dagger 提供了八种语言的 SDK，并能在任何兼容 OCI 系统的容器中运行管道，通过内容地址对操作进行缓存。因此，同一管道既可以在笔记本电脑又可以在 CI 服务器上运行。Cloudflare 则做出了相反的权衡，将执行绑定到工作流和沙箱中，以此换取状态可恢复。

这种架构转变是从可恢复执行转向了语法层面：工作流会为每个步骤设置检查点，并从最后一个执行成功的步骤开始重放，使管道在发生故障时仍然能够继续运行，而非从头开始重跑。在检查、比较差异和基于策略进行管控方面，声明式配置依然更为便捷，而通用编程语言虽然带来了更强的表达能力，却是以牺牲可读性为代价。对于已经使用 Cloudflare 技术栈的团队而言，该 SDK 消除了粘合代码，并提供了步骤级的可观测性。对于其他团队而言，可借鉴的理念包括每一步的持久化重试机制，以及一个在合并之前就停止操作的修复代理。

原文链接：https://www.infoq.com/news/2026/08/cloudflare-ci-code-workflows/