在您的平台上为数百万个仓库运行 CI/CD
我们正在朝着一个可以完全在 Cloudflare 上存储、构建、测试和部署代码的世界迈进。我们首先推出了 <a href="https://developers.cloudflare.com/artifacts/">Artifacts</a>，这是一个可扩展到数百万个仓库的版本化代码存储。
我们通过 <a href="https://github.com/cloudflare/ci">CI SDK</a> 将存储、构建和部署步骤结合在一起，基于 <a href="https://developers.cloudflare.com/workflows/">Cloudflare Workflows</a>，让您可以在 Cloudflare 上运行持续集成（CI）管道。您可以直接将 <code>artifact push</code> 事件发送到您的 Workflow，触发执行实例—本质上是一个 CI 作业—通过您 wrangler 配置文件中的新 <code>events</code> 字段。
然后，从安装了 <a href="https://www.npmjs.com/package/@cloudflare/ci">@cloudflare/ci</a> 的 Workflow，您可以：
- 自动化构建：在安全、隔离的环境中编译来自 Artifacts 仓库的代码
- 运行 linter 和类型检查：强制执行代码风格，捕捉类型错误，并标记潜在问题
- 缓存依赖项：仅运行一次 <code>install</code> 并在 CI 作业的各个步骤中缓存依赖项
- 执行单元测试：验证代码的每个部分是否按预期工作
- 自愈：集成 AI 审查代理，以捕捉构建中出现的错误步骤并推送修复提交
- 条件部署：仅在构建步骤成功时自动部署代码
今天，每个人都在构建平台，无论是内部的编程平台，还是通过代码定制客户面向产品的扩展。<a href="https://x.com/dillon_mulroy/status/2077508376217452866">平台现在使用数百万个 Artifacts 仓库</a> 存储他们的代码和客户的代码，并在两者之间进行版本控制。但每个团队对持续集成和部署管道的需求各不相同。对于平台，他们可能希望为自己的代码定义一个与客户不同的 CI 作业。
许多在这些平台上构建的最终客户不希望额外管理他们的持续集成和持续部署（CI/CD）管道。相反，平台可以代表他们的客户管理构建过程：只需编写一次 CI/CD 管道并在客户构建的所有应用程序中共享。一些平台的客户可能希望定义自己的 CI；如果是这样，他们可以编写自己的 Workflow 并在自己的仓库上运行自定义 CI 作业，得益于 <a href="https://blog.cloudflare.com/dynamic-workflows/">动态工作流</a>。美妙的是，您无需选择：平台管理的和自定义的 CI 可以同时运行，且在同一命名空间内。
## CI/CD 管道即 Workflow
在今天之前，我们拥有所有允许平台将其 CI/CD 管道在 Cloudflare 上连至在一起的组件。现在，我们正在提升开发者体验，让其更简单。
CI/CD 管道——通常通过 GitHub Actions 协调——是一系列按特定顺序运行的步骤，如果任何步骤失败，则停止运行管道并报告错误。实质上，CI/CD 管道与 Workflow 是等效的。当通过 YAML 文件定义的 CI/CD，往往会因约束条件的复杂性而迅速导致 YAML 疲劳。但 CI/CD 管道中的每一步可以简单地转换为 Workflow <code>step.do()</code>。您可以在 TypeScript 中定义 CI/CD 管道，以获得更大的自定义和灵活性。
我们正在推出新的工具 <a href="https://github.com/cloudflare/ci">CI SDK</a>，允许您在安全、隔离的环境中运行 CI 管道中的每个步骤（例如 <code>build</code>、<code>lint</code> 和 <code>typecheck</code），直接基于 Cloudflare 的开发者平台通过 Workflows 和 <a href="https://developers.cloudflare.com/sandbox/">Sandbox SDK</a> 构建。此外，您现在可以直接在推送时启动一个 CI 作业，而无需配置事件订阅、队列和队列消费者。
以前，您需要直接调用 Sandbox API，并在 CI 管道的不同步骤之间管理状态。SDK 允许您在每个 Workflow 步骤中运行每个沙箱命令，提供 Cloudflare Workflows 内置的重试和超时功能。
您还可以通过缓存步骤结果来加速 CI 管道——例如，缓存您的安装步骤——这样就不需要为后续所有操作重新安装。依赖项缓存减少了 CI/CD 管道的延迟，因为每个 CI 步骤都无需重新运行安装。
要定义 CI 作业，您只需：
1. 定义您任何依赖项的 <code>install</code> 步骤（外部包或 CI 作业所需的工具），例如 <a href="https://developers.cloudflare.com/workers/wrangler/bundling/">打包工具</a>（例如 <a href="https://esbuild.github.io/">esbuild</a>）、linter（例如 <a href="https://typescript-eslint.io/">eslint</a>）或 <a href="https://developers.cloudflare.com/workers/testing/vitest-integration/test-apis/">测试运行器</a>（例如 <a href="https://vitest.dev/">vitest</a>）。
2. 为 CI 作业中的每个步骤指定命令（例如 <code>bun run build</code>、<code>bun run test</code>、<code>bun run lint</code>）。缓存依赖项后，每个 CI 步骤可以并行执行，减少整体的延迟。
3. 在 <code>deploy</code> 步骤中传递 <code>wrangler</code> <code>deploy</code>。当 CI 管道通过时，您的 Worker 将自动部署。
编写您自己的 Workflow 中的 CI 管道，允许您尽可能多地自定义。例如，您可以从 CI Workflow 中调用一个代理，以使您的 CI 作业具备自愈功能：如果构建中的某一步出错，代理可以自动修复并推送提交供您批准。
请尝试使用 Project Think 的自愈 CI Workflows 示例：<a href="https://github.com/cloudflare/ci/blob/main/examples/self-healing">https://github.com/cloudflare/ci/blob/main/examples/self-healing</a>
## 编写您自己的 CI Workflow
要编写您自己的 CI Workflow，请从 <code>import { CIWorkflow } from @cloudflare/ci</code> 开始。
从 <code>install</code> 步骤开始：
- 下载您的依赖项，包括 CI 步骤所需的任何外部工具或库（例如 <code>vite</code>、<code>react</code>）。
- 指定您的锁定文件，以追踪依赖项是否已更改。
- 通过 <a href="https://developers.cloudflare.com/sandbox/api/backups/#createbackup">沙箱快照</a> 来缓存您的依赖项，以便后续所有步骤都可以访问。快照将存储在您帐户的 R2 存储桶中。
然后为构建和检查定义步骤，每一步都在独立的安全沙箱环境中执行。
默认情况下，Workflow中的每个步骤都是独立启动的，这意味着步骤会并发执行，除非另有指定。并行运行每个步骤可以减少 CI 运行的延迟。要确保在 CI 管道继续之前所有检查完成（例如，在部署步骤开始之前完成 <code>build</code>、<code>lint</code>、<code>test</code> 和 <code>typecheck</code>），可以将其包裹在 <code>Promise.all()</code> 中。
现在，要实际触发您的 CI Workflow，请在 Worker 的 wrangler 配置中添加 <code>events</code> 字段，同时与您的 Workflow 和 Artifact 绑定在一起。<code>events</code> 字段是您 <code>triggers</code> 字段中支持的新字段。
您已经可以通过 Cloudflare Queues <a href="https://developers.cloudflare.com/artifacts/guides/event-subscriptions/">订阅 Artifacts</a> 并在每次发生推送事件时启动构建管道。但这需要设置事件订阅、队列、消费者和队列处理程序。现在，您可以通过该事件来定位 Workflow——每次该事件触发时，它将触发一个 Workflow 实例。
将 CI Workflow 指定为 <code>artifact push</code> 触发器的目标，以便在每次 <code>cf.artifacts.repo.pushed</code> 事件时自动触发 Workflow 实例。每次 CI 运行会显示为 Workflow 实例，因此您可以在 Workflows 仪表板中查看其逐步执行和可观察性。如果您希望在命名空间中的每个仓库上运行 CI Workflow——例如，如果您是一个平台，正在对所有客户的存储库运行 CI——请省略 <code>repoName</code>，并仅在 <code>filter</code> 中指定 <code>namespace</code>。
要完全配置 CI Workflow，添加每个支持管道的基础设施部分的绑定：<code>artifacts</code>、<code>workflows</code>、<code>containers</code> 和 <code>durable_objects</code>（以及 <code>exports</code> 配置）绑定（以访问您的沙箱），如果您使用 <code>cache</code>，还需要一个 <code>r2</code> 绑定。R2 绑定是必需的，因为您的 <code>install</code> 步骤沙箱的快照存储在 <a href="https://developers.cloudflare.com/r2/buckets/">存储桶</a> 中。
## 自愈 CI 运行
要让您的 CI 作业具备自愈功能，您需要两个组件：LLM 和它的代理工具。在上面的示例中，我们包括了一个 <a href="https://developers.cloudflare.com/agents/harnesses/think/">Think 代理</a>，使用 <a href="https://developers.cloudflare.com/workers-ai/">Workers AI</a> 来捕获管道中的错误并代表您运行修复。您的 CI 作业可以远程运行和重新运行——无须一直打开笔记本电脑或每隔几分钟查看一次。相反，Cloudflare 将在云中处理，连同 CI 步骤一起在容器中运行您的自愈代理。您只需在代理修复完成后合并提交，而无需监视 CI 作业、进行手动修复和重新运行管道。
要设置自愈 CI 管道的代理，请为您的 Think 代理添加 Durable Object 绑定：
创建您的 Think 代理—<code>Healer</code>—通过扩展 <code>HealingAgent</code> 类，其中包括一个在失败时调用的 <code>heal</code> 方法。传递您希望使用的模型：
然后，将您的步骤包装在 <code>try/catch</code> 块中，失败时触发修复代理：
这个示例展示了自愈 CI 管道，但实际上，“自定义工作流”模型允许您根据需要自定义 CI 作业。这可以是可添加安全规则、过滤器或条件 CI 步骤的地方。通过 BYO-W 模型，平台可以根据各自的用例配置不同团队、客户或应用程序的 CI/CD 管道。
## 使用 Workflow 的好处
通过在 Cloudflare Workflow 上运行 CI 管道，您自动继承：
1. **弹性的重试（持久执行）：** 如果 CI 作业中的任何步骤失败，它将自动重试，同时保持状态，从而确保没有进度丢失。每个步骤支持自定义重试和超时行为，因此您可以为每个步骤定义不同的失败逻辑。此外，您可以 <a href="https://developers.cloudflare.com/workflows/build/workers-api/#restart">从特定步骤重新启动</a>，例如，如果仅 lint 失败，您无需重新运行整个 CI 管道。
2. **Workflows 可观察性：** 在 Workflows 仪表板中逐步检查 CI 作业，每个实例显示其步骤及其输入、输出以及墙面和 CPU 时间。您可以通过 <a href="https://developers.cloudflare.com/workflows/build/visualizer/">Workflows 图表</a> 在仪表板上可视化您的 CI 作业，轻松查看并行与顺序执行的步骤。您还可以通过 <a href="https://developers.cloudflare.com/workers/observability/">Workers 可观察性</a> 和 <a href="https://developers.cloudflare.com/workflows/observability/metrics-analytics/#query-via-the-graphql-api">GraphQL</a> 检查 Workflows 日志，以了解有关 CI 作业运行的更多信息。
3. **代码的力量：** 通过在 Workflow 中运行 CI，您可以为任何想要的步骤编写代码。例如，您可能希望在 CI/CD 管道中作为一部分运行 AI 代码审查工具。您可以调用您的代码审查代理，或者通过 Workflows <a href="https://developers.cloudflare.com/workflows/build/workers-api/#step">step.do()</a> 处理您可以在代码中放入的任何自定义逻辑。其他例子可能包括将构建工件写入 R2，并在 CI 失败、完成或合并到主分支时发送电子邮件。
## 接下来是什么
CI/CD 管道就是 Workflow——使用 CI SDK，您可以在简单的 TypeScript 中定义您的 CI，包括客户的代码，而不是不灵活的 YAML。基于 Cloudflare Workflows 原理，您可以定义任何所需的逻辑，无论是自愈代理（如我们的 Think 示例）还是将构建工件写入 R2。通过 Workflows 运行 CI 有助于弥合存储（通过 Artifacts）、构建和部署之间的差距。作为平台，这使您能够轻松管理自己代码以及客户的每个步骤。
<a href="http://forms.gle/DwBoPRa3CWQ8ajFp7?cf_target_id=37346A378E06FC53CEE53925EE8AAF47">请求加入</a> Artifacts 私有测试版，并开始使用我们 <a href="https://developers.cloudflare.com/artifacts/guides/build-and-deploy-on-push/">Workflows CI 指南</a>。如果您有任何功能请求或发现任何错误，欢迎通过加入 <a href="https://discord.cloudflare.com/">Cloudflare Developers 社区 Discord 频道</a> 直接与 Cloudflare 团队分享反馈。
接下来将推出：
1. Workers 和平台 Workers 的直接集成：<code>build.preview()</code> 和 <code>build.deploy()</code> 原语，在推送到主分支时自动部署，并在推送到非默认分支时创建预览
2. 渐进式部署：通过 Workflows 管理基于百分比的发布，以自定义您的发布进度和回滚逻辑
3. 单体仓库：使用单一 CI 管道简化多 Worker 部署的管理
4. 触发器：从不同来源发送推送事件，以在任何版本控制系统的仓库上运行 CI 作业，而不仅仅是 Artifacts。
---
原文链接：[点击查看](https://blog.cloudflare.com/ci-workflows/)
我们通过 <a href="https://github.com/cloudflare/ci">CI SDK</a> 将存储、构建和部署步骤结合在一起，基于 <a href="https://developers.cloudflare.com/workflows/">Cloudflare Workflows</a>，让您可以在 Cloudflare 上运行持续集成（CI）管道。您可以直接将 <code>artifact push</code> 事件发送到您的 Workflow，触发执行实例—本质上是一个 CI 作业—通过您 wrangler 配置文件中的新 <code>events</code> 字段。
然后，从安装了 <a href="https://www.npmjs.com/package/@cloudflare/ci">@cloudflare/ci</a> 的 Workflow，您可以：
- 自动化构建：在安全、隔离的环境中编译来自 Artifacts 仓库的代码
- 运行 linter 和类型检查：强制执行代码风格，捕捉类型错误，并标记潜在问题
- 缓存依赖项：仅运行一次 <code>install</code> 并在 CI 作业的各个步骤中缓存依赖项
- 执行单元测试：验证代码的每个部分是否按预期工作
- 自愈：集成 AI 审查代理，以捕捉构建中出现的错误步骤并推送修复提交
- 条件部署：仅在构建步骤成功时自动部署代码
今天，每个人都在构建平台，无论是内部的编程平台，还是通过代码定制客户面向产品的扩展。<a href="https://x.com/dillon_mulroy/status/2077508376217452866">平台现在使用数百万个 Artifacts 仓库</a> 存储他们的代码和客户的代码，并在两者之间进行版本控制。但每个团队对持续集成和部署管道的需求各不相同。对于平台，他们可能希望为自己的代码定义一个与客户不同的 CI 作业。
许多在这些平台上构建的最终客户不希望额外管理他们的持续集成和持续部署（CI/CD）管道。相反，平台可以代表他们的客户管理构建过程：只需编写一次 CI/CD 管道并在客户构建的所有应用程序中共享。一些平台的客户可能希望定义自己的 CI；如果是这样，他们可以编写自己的 Workflow 并在自己的仓库上运行自定义 CI 作业，得益于 <a href="https://blog.cloudflare.com/dynamic-workflows/">动态工作流</a>。美妙的是，您无需选择：平台管理的和自定义的 CI 可以同时运行，且在同一命名空间内。
## CI/CD 管道即 Workflow
在今天之前，我们拥有所有允许平台将其 CI/CD 管道在 Cloudflare 上连至在一起的组件。现在，我们正在提升开发者体验，让其更简单。
CI/CD 管道——通常通过 GitHub Actions 协调——是一系列按特定顺序运行的步骤，如果任何步骤失败，则停止运行管道并报告错误。实质上，CI/CD 管道与 Workflow 是等效的。当通过 YAML 文件定义的 CI/CD，往往会因约束条件的复杂性而迅速导致 YAML 疲劳。但 CI/CD 管道中的每一步可以简单地转换为 Workflow <code>step.do()</code>。您可以在 TypeScript 中定义 CI/CD 管道，以获得更大的自定义和灵活性。
我们正在推出新的工具 <a href="https://github.com/cloudflare/ci">CI SDK</a>，允许您在安全、隔离的环境中运行 CI 管道中的每个步骤（例如 <code>build</code>、<code>lint</code> 和 <code>typecheck</code），直接基于 Cloudflare 的开发者平台通过 Workflows 和 <a href="https://developers.cloudflare.com/sandbox/">Sandbox SDK</a> 构建。此外，您现在可以直接在推送时启动一个 CI 作业，而无需配置事件订阅、队列和队列消费者。
以前，您需要直接调用 Sandbox API，并在 CI 管道的不同步骤之间管理状态。SDK 允许您在每个 Workflow 步骤中运行每个沙箱命令，提供 Cloudflare Workflows 内置的重试和超时功能。
您还可以通过缓存步骤结果来加速 CI 管道——例如，缓存您的安装步骤——这样就不需要为后续所有操作重新安装。依赖项缓存减少了 CI/CD 管道的延迟，因为每个 CI 步骤都无需重新运行安装。
要定义 CI 作业，您只需：
1. 定义您任何依赖项的 <code>install</code> 步骤（外部包或 CI 作业所需的工具），例如 <a href="https://developers.cloudflare.com/workers/wrangler/bundling/">打包工具</a>（例如 <a href="https://esbuild.github.io/">esbuild</a>）、linter（例如 <a href="https://typescript-eslint.io/">eslint</a>）或 <a href="https://developers.cloudflare.com/workers/testing/vitest-integration/test-apis/">测试运行器</a>（例如 <a href="https://vitest.dev/">vitest</a>）。
2. 为 CI 作业中的每个步骤指定命令（例如 <code>bun run build</code>、<code>bun run test</code>、<code>bun run lint</code>）。缓存依赖项后，每个 CI 步骤可以并行执行，减少整体的延迟。
3. 在 <code>deploy</code> 步骤中传递 <code>wrangler</code> <code>deploy</code>。当 CI 管道通过时，您的 Worker 将自动部署。
编写您自己的 Workflow 中的 CI 管道，允许您尽可能多地自定义。例如，您可以从 CI Workflow 中调用一个代理，以使您的 CI 作业具备自愈功能：如果构建中的某一步出错，代理可以自动修复并推送提交供您批准。
请尝试使用 Project Think 的自愈 CI Workflows 示例：<a href="https://github.com/cloudflare/ci/blob/main/examples/self-healing">https://github.com/cloudflare/ci/blob/main/examples/self-healing</a>
## 编写您自己的 CI Workflow
要编写您自己的 CI Workflow，请从 <code>import { CIWorkflow } from @cloudflare/ci</code> 开始。
从 <code>install</code> 步骤开始：
- 下载您的依赖项，包括 CI 步骤所需的任何外部工具或库（例如 <code>vite</code>、<code>react</code>）。
- 指定您的锁定文件，以追踪依赖项是否已更改。
- 通过 <a href="https://developers.cloudflare.com/sandbox/api/backups/#createbackup">沙箱快照</a> 来缓存您的依赖项，以便后续所有步骤都可以访问。快照将存储在您帐户的 R2 存储桶中。
然后为构建和检查定义步骤，每一步都在独立的安全沙箱环境中执行。
默认情况下，Workflow中的每个步骤都是独立启动的，这意味着步骤会并发执行，除非另有指定。并行运行每个步骤可以减少 CI 运行的延迟。要确保在 CI 管道继续之前所有检查完成（例如，在部署步骤开始之前完成 <code>build</code>、<code>lint</code>、<code>test</code> 和 <code>typecheck</code>），可以将其包裹在 <code>Promise.all()</code> 中。
现在，要实际触发您的 CI Workflow，请在 Worker 的 wrangler 配置中添加 <code>events</code> 字段，同时与您的 Workflow 和 Artifact 绑定在一起。<code>events</code> 字段是您 <code>triggers</code> 字段中支持的新字段。
您已经可以通过 Cloudflare Queues <a href="https://developers.cloudflare.com/artifacts/guides/event-subscriptions/">订阅 Artifacts</a> 并在每次发生推送事件时启动构建管道。但这需要设置事件订阅、队列、消费者和队列处理程序。现在，您可以通过该事件来定位 Workflow——每次该事件触发时，它将触发一个 Workflow 实例。
将 CI Workflow 指定为 <code>artifact push</code> 触发器的目标，以便在每次 <code>cf.artifacts.repo.pushed</code> 事件时自动触发 Workflow 实例。每次 CI 运行会显示为 Workflow 实例，因此您可以在 Workflows 仪表板中查看其逐步执行和可观察性。如果您希望在命名空间中的每个仓库上运行 CI Workflow——例如，如果您是一个平台，正在对所有客户的存储库运行 CI——请省略 <code>repoName</code>，并仅在 <code>filter</code> 中指定 <code>namespace</code>。
要完全配置 CI Workflow，添加每个支持管道的基础设施部分的绑定：<code>artifacts</code>、<code>workflows</code>、<code>containers</code> 和 <code>durable_objects</code>（以及 <code>exports</code> 配置）绑定（以访问您的沙箱），如果您使用 <code>cache</code>，还需要一个 <code>r2</code> 绑定。R2 绑定是必需的，因为您的 <code>install</code> 步骤沙箱的快照存储在 <a href="https://developers.cloudflare.com/r2/buckets/">存储桶</a> 中。
## 自愈 CI 运行
要让您的 CI 作业具备自愈功能，您需要两个组件：LLM 和它的代理工具。在上面的示例中，我们包括了一个 <a href="https://developers.cloudflare.com/agents/harnesses/think/">Think 代理</a>，使用 <a href="https://developers.cloudflare.com/workers-ai/">Workers AI</a> 来捕获管道中的错误并代表您运行修复。您的 CI 作业可以远程运行和重新运行——无须一直打开笔记本电脑或每隔几分钟查看一次。相反，Cloudflare 将在云中处理，连同 CI 步骤一起在容器中运行您的自愈代理。您只需在代理修复完成后合并提交，而无需监视 CI 作业、进行手动修复和重新运行管道。
要设置自愈 CI 管道的代理，请为您的 Think 代理添加 Durable Object 绑定：
创建您的 Think 代理—<code>Healer</code>—通过扩展 <code>HealingAgent</code> 类，其中包括一个在失败时调用的 <code>heal</code> 方法。传递您希望使用的模型：
然后，将您的步骤包装在 <code>try/catch</code> 块中，失败时触发修复代理：
这个示例展示了自愈 CI 管道，但实际上，“自定义工作流”模型允许您根据需要自定义 CI 作业。这可以是可添加安全规则、过滤器或条件 CI 步骤的地方。通过 BYO-W 模型，平台可以根据各自的用例配置不同团队、客户或应用程序的 CI/CD 管道。
## 使用 Workflow 的好处
通过在 Cloudflare Workflow 上运行 CI 管道，您自动继承：
1. **弹性的重试（持久执行）：** 如果 CI 作业中的任何步骤失败，它将自动重试，同时保持状态，从而确保没有进度丢失。每个步骤支持自定义重试和超时行为，因此您可以为每个步骤定义不同的失败逻辑。此外，您可以 <a href="https://developers.cloudflare.com/workflows/build/workers-api/#restart">从特定步骤重新启动</a>，例如，如果仅 lint 失败，您无需重新运行整个 CI 管道。
2. **Workflows 可观察性：** 在 Workflows 仪表板中逐步检查 CI 作业，每个实例显示其步骤及其输入、输出以及墙面和 CPU 时间。您可以通过 <a href="https://developers.cloudflare.com/workflows/build/visualizer/">Workflows 图表</a> 在仪表板上可视化您的 CI 作业，轻松查看并行与顺序执行的步骤。您还可以通过 <a href="https://developers.cloudflare.com/workers/observability/">Workers 可观察性</a> 和 <a href="https://developers.cloudflare.com/workflows/observability/metrics-analytics/#query-via-the-graphql-api">GraphQL</a> 检查 Workflows 日志，以了解有关 CI 作业运行的更多信息。
3. **代码的力量：** 通过在 Workflow 中运行 CI，您可以为任何想要的步骤编写代码。例如，您可能希望在 CI/CD 管道中作为一部分运行 AI 代码审查工具。您可以调用您的代码审查代理，或者通过 Workflows <a href="https://developers.cloudflare.com/workflows/build/workers-api/#step">step.do()</a> 处理您可以在代码中放入的任何自定义逻辑。其他例子可能包括将构建工件写入 R2，并在 CI 失败、完成或合并到主分支时发送电子邮件。
## 接下来是什么
CI/CD 管道就是 Workflow——使用 CI SDK，您可以在简单的 TypeScript 中定义您的 CI，包括客户的代码，而不是不灵活的 YAML。基于 Cloudflare Workflows 原理，您可以定义任何所需的逻辑，无论是自愈代理（如我们的 Think 示例）还是将构建工件写入 R2。通过 Workflows 运行 CI 有助于弥合存储（通过 Artifacts）、构建和部署之间的差距。作为平台，这使您能够轻松管理自己代码以及客户的每个步骤。
<a href="http://forms.gle/DwBoPRa3CWQ8ajFp7?cf_target_id=37346A378E06FC53CEE53925EE8AAF47">请求加入</a> Artifacts 私有测试版，并开始使用我们 <a href="https://developers.cloudflare.com/artifacts/guides/build-and-deploy-on-push/">Workflows CI 指南</a>。如果您有任何功能请求或发现任何错误，欢迎通过加入 <a href="https://discord.cloudflare.com/">Cloudflare Developers 社区 Discord 频道</a> 直接与 Cloudflare 团队分享反馈。
接下来将推出：
1. Workers 和平台 Workers 的直接集成：<code>build.preview()</code> 和 <code>build.deploy()</code> 原语，在推送到主分支时自动部署，并在推送到非默认分支时创建预览
2. 渐进式部署：通过 Workflows 管理基于百分比的发布，以自定义您的发布进度和回滚逻辑
3. 单体仓库：使用单一 CI 管道简化多 Worker 部署的管理
4. 触发器：从不同来源发送推送事件，以在任何版本控制系统的仓库上运行 CI 作业，而不仅仅是 Artifacts。
---
原文链接：[点击查看](https://blog.cloudflare.com/ci-workflows/)
评论
暂无评论。