为数百万仓库运行 CI/CD——可以在你自己的平台，也可以在 Cloudflare
我们正在走向这样一个世界：存储、构建、测试、部署代码，都可以完全在 Cloudflare 上完成。其中的第一块拼图是 Artifacts——一种带版本管理的代码存储服务，可以扩展到数百万个仓库。借助构建在 Cloudflare Workflows 之上的 CI SDK，我们把“存储、构建、部署”这几个步骤串了起来，让你能直接在 Cloudflare 上运行持续集成（CI）流水线。
在 wrangler 配置文件中新增一个 events 字段，就可以把 Artifacts 推送事件直接发到你的 Workflow，从而触发一次执行——本质上就是一个 CI 任务。接着，在安装了 @cloudflare/ci 的 Workflow 里，你可以：
- 自动化构建：在安全隔离的环境中编译 Artifacts 仓库中的代码
- 运行 lint 与类型检查：强制执行代码风格，捕获类型错误，并标记任何潜在问题
- 缓存依赖：只安装一次依赖，并在 CI 任务的各个步骤之间复用缓存
- 执行单元测试：验证每一段代码的行为是否符合预期
- 自愈：集成 AI 审查代理，让它识别构建中失败的步骤，并自动推送修复提交
- 条件部署：只在构建步骤成功时自动部署你的代码
如今，人人都在打造平台——可能是内部的 vibe coding（随性编程）平台，也可能是通过代码定制为客户产品所做的扩展。这些平台现在用 Artifacts 里的数百万个代码仓库来存放自己的代码、客户的代码，并对两者做版本控制。但每个团队对持续集成和持续部署流水线都有自己的需求。
对于平台方来说，他们为自己的代码定义 CI 任务的方式，可能需要和为客户定义的方式区别开。很多在这些平台上构建应用的终端客户，并不想再为管理自己的持续集成和持续部署（CI/CD）流水线多费心思。取而代之的是，平台可以替客户管理构建流程：把 CI/CD 流水线写好一次，然后复用到客户正在构建的所有应用上。
平台的客户如果希望定义自己的 CI，完全可以自己编写 Workflow，借助动态工作流在自己的仓库里跑自定义 CI 任务。好处是不用二选一：平台托管的自定义 CI 可以同时运行，而且共享同一个命名空间。
CI/CD 管道，本质上就是一个 Workflow
在今天的发布之前，我们已经具备让平台在 Cloudflare 上串联起 CI/CD 管道的各种能力。现在，我们要把这些能力整合成更完善的开发者体验，让它变得简单直接。
CI/CD 管道——通常用 GitHub Actions 编排——就是一系列按特定顺序执行的步骤，任何一步失败都会停止整个管道并上报错误。从这个角度看，CI/CD 管道本质上就是一个 Workflow。
用 YAML 文件定义 CI/CD，往往会因为各种限制迅速变得复杂，这也正是大家常说的“YAML 疲劳”。但管道中的每一步，其实都可以简单对应为 Workflow 的 step.do()。与其用 YAML，不如用 TypeScript 来定义 CI/CD 管道，定制和配置的自由度都更高。
我们在 CI SDK 中推出了新工具，让管道中的每个步骤（比如 build、lint、typecheck）都能跑在安全、隔离的环境里，底层直接由 Cloudflare 开发者平台通过 Workflows 和 Sandbox SDK 支撑。另外，现在可以在 push 事件发生时就立即启动 CI 任务，而不再需要手动配置事件订阅、队列和队列消费者。
以前，你需要直接调用 Sandbox API，还要自己管理管道各步骤之间的状态。现在，SDK 让你可以把每条沙箱命令放进独立的 Workflow 步骤中，自动获得 Cloudflare Workflows 内置的重试和超时机制。
此外，你还可以通过缓存步骤结果来提速——比如把 install 步骤缓存起来，后续操作就不用每次都重新安装依赖。依赖缓存能显著降低 CI/CD 管道的延迟，因为不是每个 CI 步骤都要重跑一遍安装流程。
定义一个 CI 任务，你只需：
- 定义安装步骤，用于准备 CI 任务所需的依赖（外部包或工具），比如打包工具（如 webpack、esbuild）等。
esbuild）、代码检查工具（如 eslint）或测试运行器（如 vitest）。为 CI 任务中的每个步骤指定命令（例如 bun run build、bun run test、bun run lint）。有了依赖缓存，每个 CI 步骤都能并行执行，从而缩短整个流水线的耗时。在部署步骤中传入 wrangler deploy，当 CI 流水线通过时，你的 Worker 就会自动部署。用 Workflow 编写自己的 CI 流水线，可以按需任意定制。比如，你可以从 CI Workflow 中调用一个 agent，让 CI 任务具备自愈能力：如果构建中的某个步骤出错，agent 可以自动修复，并推送一个提交供你审批。你可以通过 Project Think 尝试一个自愈 CI Workflow 的示例：https://github.com/cloudflare/ci/blob/main/examples/self-healing
编写你自己的 CI Workflow
要编写你自己的 CI Workflow，先从 import { CIWorkflow } from@cloudflare/ci 开始。先从一个安装步骤开始：下载你的依赖，包括 CI 步骤所需的外部工具或库（例如 vite、react）。指定你的 lockfile，它会跟踪依赖是否发生了变化。通过沙箱快照缓存你的依赖，这样后续所有步骤都可以访问。快照将存储在你账户下的 R2 bucket 中。
然后为构建和检查定义步骤，每一步都在各自安全、隔离的沙箱环境中执行。默认情况下，Workflow 中的每个步骤都是独立启动的，也就是说，除非另有指定，各步骤会并发执行。并行运行每个步骤可以降低 CI 运行的延迟。为了确保所有检查在 CI 流水线继续之前完成（例如在部署步骤开始前完成 build、lint、test 和 typecheck），请用 Promise.all() 包裹起来：
现在，要真正触发你的 CI Workflow，请在 Worker 的 wrangler 配置中，连同 Workflow 和 Artifact 绑定一起，添加一个 events 字段。events 字段是 triggers 字段中新增的一个字段。在此之前，你已经可以通过事件订阅，借助 Cloudflare Queues 订阅 Artifacts，并在每次有 push 事件时启动一条构建流水线。
在 Cloudflare 上，为你的平台运行覆盖数百万仓库的 CI/CD
但这需要你自行搭建事件订阅、Queue、消费者和队列处理器。现在，你可以直接用事件去触发一个 Workflow——每当事件发生，就会启动一个 Workflow 实例。把 CI Workflow 设为构件推送触发器（artifact push trigger）的目标，就能在每次 cf.artifacts.repo.pushed 事件出现时，自动触发一个 Workflow 实例。
每次 CI 运行都会以一个 Workflow 实例的形式呈现，你可以直接在 Workflows 控制台中查看它的分步执行过程和可观测性数据。这是一个以 Artifacts 为核心的集成方案；后续事件类型还会支持来自 Cloudflare 账户内各种数据源的事件，方便你在整个产品套件中以编程方式调用。
如果你希望让 CI Workflow 覆盖命名空间里的每一个仓库——比如你是一个平台方，要为所有客户的仓库跑 CI——那么在 filter 中省略 repoName、只指定 namespace 即可。
要完整配置 CI Workflow，需要为管线的各个基础组件添加绑定：artifacts、workflows、containers，以及 durable_objects（外加 exports 配置）绑定（用于访问沙箱）；如果启用了缓存，还需要加一个 r2 绑定。r2 绑定是必需的，因为安装步骤中沙箱的快照就存放在 R2 存储桶里。
CI 运行的自愈机制
要让 CI 任务具备自愈能力，你需要两样东西：大语言模型（LLM）和它的智能体运行框架（agent harness）。在上面的示例中，我们加入了一个基于 Workers AI 的 Think 智能体，它负责捕获管线中的错误，并代替你执行修复。
CI 任务可以在云端反复运行——你不再需要抱着笔记本盯着进度，也不用每隔几分钟就回来看一眼。Cloudflare 会在云端处理这一切，把修复智能体（healer agent）和 CI 步骤一起放进容器里运行。你不再需要守着 CI 任务、手动修复问题、再重跑一遍管线；智能体改完代码之后，你只需要合并提交即可。
要为 CI 管线配置自愈智能体，先给 Think 智能体添加一个 Durable Object 绑定：继承 HealingAgent 类，创建你自己的 Think 智能体——Healer。HealingAgent 内置了 heal 方法，在构建失败时供你调用。
在自己的平台上、在 Cloudflare 上，为数百万仓库运行 CI/CD
想用哪个模型都可以，任你选择。然后，把步骤包在 try/catch 块里，一旦失败就触发修复代理：
这个例子演示了一个自愈式 CI 流水线，不过说到底，「自带工作流」模式（Bring Your Own Workflow）能让你随心所欲地定制 CI 任务。你可以在这里加入安全规则、过滤器，或者条件化的 CI 步骤。借助 BYO-W 模式，平台方可以根据每个团队、客户或应用的具体场景，灵活配置各自的 CI/CD 流水线。
使用 Workflow 的好处
把 CI 流水线跑在 Cloudflare Workflow 上，你可以自动获得：
- 弹性重试（持久化执行）：如果 CI 任务中的任何一步失败，系统会自动重试，而且状态会被保留下来，意味着之前的进度不会丢失。每一步都支持自定义重试和超时行为，你可以为每个步骤定义不同的失败处理逻辑。另外，你还可以从指定步骤重新开始——比如只是 lint 挂了，就不必把整个 CI 流水线从头再跑一遍。
- Workflow 可观测性：在 Workflows 控制台里，你可以一步步查看 CI 任务的执行情况，每个实例都会展示各步骤的输入、输出，以及实际耗时和 CPU 时间。你还可以通过控制台里的 Workflows 图直观地查看 CI 任务，一眼看出哪些步骤是并行跑、哪些是串行跑。此外，你还能通过 Workers Observability 和 GraphQL 查看 Workflows 日志，更深入地了解每次 CI 运行的细节。
- 代码的力量：把 CI 放到 Workflow 里跑，你就等于可以用代码写任何想要的步骤。比如，你可能想在 CI/CD 流水线里加一个 AI 代码审查器。你可以直接调用代码审查代理——或者处理任何你能写进代码里的自定义逻辑——通过 Workflows 的
step.do()方法。再比如，把构建产物写入 R2，或者在 CI 失败、完成或合并到 main 时发送邮件通知。
接下来是什么
CI/CD 流水线本质上就是一个 Workflow——借助 CI SDK，你可以在代码里定义 CI 流程，包括你自己和你客户的，用简洁的 TypeScript 而不是僵硬的 YAML。
基于 Cloudflare Workflows 原语，你可以定义任何自己想要的逻辑，无论是像我们的 Think 示例那样的修复代理，还是将构建产物写入 R2。在 Workflows 上运行 CI 有助于弥合存储（通过 Artifacts）、构建和部署之间的差距。作为平台，这让你可以轻松地管理自己的代码，也可以代表客户管理每个步骤。请求加入 Artifacts 私有测试版，并从我们的 Workflows CI 指南开始上手。如果你有任何功能请求或发现 bug，可以直接加入 Discord 上的 Cloudflare 开发者社区，向 Cloudflare 团队反馈你的意见。
接下来即将推出：