EdgeOne 绑定 CNB 仓库，部署快了一半

本站是部署在EdgeOne Pages上的，用cnb.cool版本管理，详见这里。本站的工作流是在本地写md文件，然后git到cnb，cnb.yml里配置相应的CI/CD，实现自动部署。见CNB文档：部署 EdgeOne Makers 插件。那时候就纳闷，为什么不能在edgeone上直接绑定cnb仓库，实现自动部署呢？毕竟已经适配了GitHub、GitLab、Bitbucket等代码仓库。自己家的仓库，还不能直接绑定。

昨天更改域名，目前的dogtor.cn域名在国内备案了，加速区域可以选择全球范围（含中国大陆）。所以要重新建一个edgeone项目。这个时候发现，CNB赫然在列，可以直接绑定。

绑定之后，发现部署失败了，检查了一下，是因为edgeone项目没有配置webhook，导致自动部署失败。"CNB 暂不支持原生 Webhook，需要通过 Webhook 插件来触发部署。请参考 CNB Webhook 插件 在您的 CNB 仓库中配置，配置完成后每次推送代码即可自动触发部署。"

让AI处理了一下，Webhook配置完成后，没想到效果拔群。之前部署要两分多钟，现在不到一分钟就可以搞定了。

总结

咨询了一下DeepSeek老师，分析了一下两种方案的耗时差异。

方案 1：在 CNB 里跑 npm run build + edgeone pages deploy

这个方案在 CNB 的流水线里做了三件事：

• npm run build：在 CNB 容器里从零开始构建，包括 npm install、编译、打包。
• edgeone pages deploy out/：调用 EdgeOne CLI，把 out/ 目录完整打包上传到 EdgeOne Pages。
• EdgeOne Pages 侧接收全量文件，再分发到 CDN。

耗时主要来自：

• CNB 构建阶段：每次都要重新跑一遍依赖安装和构建（除非 CNB 流水线本身配了缓存）。
• 上传阶段：EdgeOne CLI 要把整个 out/ 目录（可能包含几百上千个静态文件）通过 HTTP 逐个或打包上传，受限于 CNB 到 EdgeOne 的网络带宽。
• EdgeOne 侧处理：接收全量文件、计算哈希、更新 CDN。

方案 2：CNB/Webhook

这个方案的本质是：CNB 把构建和部署都交给了 EdgeOne Pages 的云端构建系统。

典型流程是：

• CNB 流水线里只做一件事——触发一个 Webhook（或者调用 EdgeOne 的 API），把代码仓库地址、分支、commit 等信息传给 EdgeOne。
• EdgeOne Pages 自己的构建系统去拉取你的仓库代码，在它自己的构建环境里执行 npm run build，然后直接部署。

耗时差异的关键在这里：

一句话总结：能交给平台自己做的，就别自己搬砖。