只用一个cnb仓库行不行呀

问题

问题：我这个oneblog博客架构方案，只用一个cnb仓库新不行呀，不用gitee仓库了，请评估下。

回复

cusor auto回复：2026年7月5日。

结论：可行，且更合理

只用 CNB 一个仓库、去掉 Gitee，技术上完全可行，而且能从根本上消除你之前遇到的「后台保存了、站点没更新」这类双仓同步问题。代码里 CNB 读写能力已经具备，主要差在 CI 和默认配置仍按「Gitee 写、CNB 建」设计。

当前架构为什么绕了一圈

本质上是 两个真相源：

所以必须维护：pull from gitee → sync to gitee → 定时 cron 拉取 → 保存后再 triggerCnbSiteRebuild。友链那次问题，根因就在这里。

单 CNB 方案长什么样

一条链路：后台写 CNB → push 触发流水线 → 直接构建部署。不再需要 Gitee 镜像、回推、定时拉取，也不需要大部分「保存后再触发重建」的补丁逻辑。

代码侧已有能力（不用从零写）

后台设置页已提示 CNB Token 需要 repo-code:r + repo-code:rw。

仍需改动的部分（迁移时）

1. .cnb.yml（必改）

以下阶段都可以删掉：

• pull from gitee before build（master.push、web_trigger、api_trigger_rebuild、cron）
• sync to gitee
• cron */30 若只为拉 Gitee，可删或改成纯定时重建

2. Admin 默认指向 CNB（建议改）

当前默认仍是 Gitee：

1  const platform = env.GIT_PLATFORM || 'gitee';
2  return {
3    platform,
4    token,
5    owner: env.GIT_OWNER || env.GITEE_OWNER || env.CNB_OWNER || env.GITHUB_OWNER || 'onlyonexl',

应改为：platform: cnb，owner: onedayxyy。

3. EdgeOne / KV 配置

后台「系统设置」里也要切到 CNB，并填 onedayxyy/hugo-teek-private。

4. 自动重建逻辑可简化

markGiteeMutation 在 platform === 'cnb' 时不会标记变更，因此 dispatchV1Api 不会走二次 triggerCnbSiteRebuild：

1function markGiteeMutation(config) {
2  if (config?._giteeMutation && config.platform !== 'cnb') {
3    config._giteeMutation.mutated = true;

单 CNB 下这其实是合理的：写入 CNB 本身就会产生 commit，触发 master.push 流水线，一般不必再写 .cnb-rebuild-trigger。

利弊对比

风险与注意点

1. 只改后台、不改 CI 会翻车
   即便后台改成写 CNB，当前 CI 仍会先 pull from gitee，构建用的还是 Gitee 旧数据。必须同步改 .cnb.yml。

2. CNB 写入权限
   Token 必须有 repo-code:rw；先在后台「测试连接」、再试保存一篇文章验证。

3. 连续保存可能连触发多次构建
   双仓时代靠「写 Gitee + 单次 trigger」有缓冲；单 CNB 每次保存都是一次 push。一般可接受，后续可加防抖。

4. Gitee 不必立刻删
   可先停用（不再写入、CI 不再拉取），保留只读备份一段时间。

建议迁移步骤

1. 确认 Gitee 与 CNB 内容已对齐（做一次最终同步或对比）。
2. 后台切到 CNB：onedayxyy/hugo-teek-private + CNB Token。
3. 测试：保存友链/公告 → 看 CNB 是否有新 commit → CI 是否自动跑。
4. 改 .cnb.yml：去掉所有 Gitee pull/sync；视情况删 cron。
5. 更新 EdgeOne 环境变量和 secret/envs.yml，去掉 Gitee 凭证。
6. 观察 1–2 天无问题后，Gitee 仓库归档或只读保留。

工作量：大约半天（配置切换 + CI 精简 + 端到端验证），不需要重写 Admin 核心逻辑。

最终建议

推荐迁到单 CNB。
你现在的双仓方案是为了规避早期 CNB API 不成熟而做的「Gitee 写、CNB 建」折中；随着 CNB 读写和 CI 已稳定，继续维护双仓的同步成本大于收益。友链、公告那类问题，在单仓下会自然消失。

如果你确认要迁，我可以下一步直接帮你改 .cnb.yml、默认配置，并整理一份迁移检查清单（不 push，等你确认后再推）。

备份

本地备份数据：

1D:\hugo-teek-private-迁移cnb单仓库-20260705

commit信息：

1$ git log
2commit b9bf46adefddd1049fd958c3db5228768d542528 (HEAD -> master)
3Merge: 7cc54c7 8eca668
4Author: nuc-it-win11 <2675263825@qq.com>
5Date:   Sun Jul 5 21:38:33 2026 +0800
6
7    Merge branch 'master' of https://cnb.cool/onedayxyy/hugo-teek-private

迁移

请帮我把全站迁移成单一cnb仓库维护吧，要求无bug。

token

1令牌名:oneblogadmin2（仓库完全读写功能）
2Git Username:cnb
3Token:3xxxxxxxxxxxxxxxxxxxxxxxxxxxxxTgR   （已加密）

仓库

 1开始把全站迁到单一 CNB 仓库：我会先梳理 Gitee 相关引用与 CI 配置，再改 Admin 默认写入目标并精简流水线。
 2
 3Auto
 4
 5迁移工作已在后台进行，会覆盖这些部分：
 6
 7CI：.cnb.yml 去掉所有 Gitee pull/sync
 8Admin：默认写入 onedayxyy/hugo-teek-private（CNB）
 9自动重建：改为依赖 CNB push 触发，避免双仓二次触发
10配置与文档：.env.example、README、后台 Git 设置页默认值
11
12完成后我会把改动清单和生产环境手动步骤（EdgeOne 环境变量、KV 设置）一并给你。
13
14!
15
16eo pages kv值
17cnb token
18博客后台前端 & cnb仓库开源api

gitee备份仓库（已实现）

1ci: sync cnb to gitee
2
3此时，有个需求，每当自己的cnb仓库有任何改变时，都给我同步到自己的gitee仓库，这个是用以做仓库备份数据使用，请给我写到ci流水线里。
4cnb仓库：https://cnb.cool/onedayxyy/hugo-teek-private （私有库）
5gitee仓库：https://gitee.com/onlyonexl/ongblog-gitee-backup（私有库）

已完成。在 .cnb.yml 的 master.push 流水线里加入了 Gitee 备份同步阶段。

改动说明

在 master.push 的 构建之前 增加了 tencentcom/git-sync 阶段，将 CNB 仓库镜像到 Gitee 备份库：

 1- name: 同步仓库到 Gitee 备份
 2  image: tencentcom/git-sync
 3  settings:
 4    branch: master
 5    auth_type: https
 6    username: ${GIT_USERNAME}
 7    password: ${GIT_ACCESS_TOKEN}
 8    target_url: https://gitee.com/onlyonexl/ongblog-gitee-backup.git
 9    push_tags: true
10    force: true

触发时机

你需要在密钥库配置的变量

在 https://cnb.cool/onedayxyy/secret/-/blob/main/envs.yml 中确认已有（你其它项目里应该已配过）：

Gitee 备份库准备

1. 确认 https://gitee.com/onlyonexl/ongblog-gitee-backup 已创建（私有库）
2. 建议创建时 不要 勾选「使用 Readme 初始化」，避免首次同步冲突
3. 若已有 README 导致首次失败，可清空该库或手动删 README 后重跑流水线

推送 .cnb.yml 到 CNB 后，下一次 master.push 就会开始自动备份到 Gitee。需要的话我可以帮你检查密钥库变量是否齐全，或协助首次同步验证。

报错

（后台无法删除友链）

已定位并修复，代码已推送（1638f86）。

根因：CNB 的 /-/git/contents 只支持 GET 读取，不支持 Gitee/GitHub 那种 POST/PUT 写入。单 CNB 迁移后，后台保存友链仍在调 Contents 写入 API，所以报 CNB API POST 404: {"errcode":5}。

修复方案：改为走 CI 流水线写入：

1. 后台保存 → 调用 api_trigger_admin_write 构建
2. CI 在仓库内改文件 → git commit → git push
3. push 再触发 master.push 完成站点构建

请你确认一件事：CNB 访问令牌需同时勾选：

• repo-code:r / repo-code:rw（读写信仓）
• repo-cnb-trigger:rw（触发流水线）

在 EdgeOne 环境变量或后台「系统设置」里更新 Token 后，再试一次删除友链。成功时提示应为「已保存，CNB 将自动构建（约 3–5 分钟）」，CNB 流水线里应能看到 api_trigger_admin_write 任务。

成功

亲测成功。

博客后台配置变更（详细）

帮检查下，博客后台图形化 相关功能配置后，是否都会默认触发ci构建呢？不要有遗漏了

已完成对 Vue 后台全量 API 与 CNB 构建链路的审计，结论如下。

触发机制（CNB 单仓架构）

后台所有 Git 写入（writeFile / deleteFile / uploadImageToGitbed）在 platform=cnb 时走：

1保存 → api_trigger_admin_write（改文件+commit+push）→ master.push（完整构建+部署）

/api/v1/* 写请求经 dispatchV1Api 包装：若 _giteeMutation.mutated=true，响应会带上 triggered: true（仅 UI 反馈，不二次触发）。

另有 显式触发（不依赖 push）：

• POST /config/merge → api_trigger_rebuild
• POST /preview/rebuild → api_trigger_rebuild

会触发站点 CI 的功能（Git 有变更）

故意不触发站点 CI（设计如此，无 Git 变更）

发现的遗漏 / 问题

1. 功能未落地（不会写 Git，也不会触发 CI）

菜单映射：编辑走 PUT /sections（整表保存）是正常的；新增/删除单条 目前是假的，需改为统一走 PUT 或补全 POST/DELETE 实现。

2. 会写 Git 但体验/效率需注意

• 主题配置多文件保存：每文件一次 api_trigger_admin_write，可能连续触发多次 CI。
• 备份导入：每个配置文件各触发一次 CI。
• 大文件限制：单文件 base64 超约 30KB 会报错，需本地 git push。
• 主题切换、文章删除、备份导入：未统一用 notifySaveResponse，成功提示可能不显示「将自动构建」。

3. 七牛模式下的「内容不生效」

图库/媒体走七牛时，不会触发站点 CI 也不会把图片写进 Git。若文章里引用的是 Git 路径，线上可能看不到新图——这是存储策略问题，不是 CI 漏触发。

总结

所有真正写入 CNB 仓库的配置/内容保存，都会默认触发 CI（admin_write → push → master.push），核心路径没有遗漏。

需要关注的不是「漏触发 CI」，而是：

1. Section 映射新增/删除、目录重命名/删除、批量操作 等尚未实现，保存了也不会改仓库。
2. 七牛存储 场景下本来就不该期待站点 CI。
3. 多文件保存会产生 多次并行 CI，属于性能问题而非覆盖缺口。

如果需要，我可以下一步直接修 Section 映射新增/删除（改为内部合并后统一 PUT /sections），并给主题多文件保存加批量合并，减少重复 CI。