hexo博客从Coding迁移到CNB云原生构建实践

发表于 | 分类于
字数统计: 15k

hexo博客从Coding迁移到CNB云原生构建实践

背景：Coding停服，被迫搬家

2020年我把Hexo博客部署到了腾讯Coding平台，利用其Jenkins CI/CD能力实现了「推送源码→云端构建→自动部署到阿里云OSS」的自动化流水线。三年多来一直稳定运行。

2026年初Coding宣布停止服务，原有构建计划无法继续使用。这意味着博客更新流程彻底中断——改一篇文章就必须本地手动 hexo g && hexo d，失去了多端推送的便利。

本文记录从Coding到CNB云原生构建的完整迁移过程，以及踩过的坑。

原架构一览

1
2
3
4
5
6
7
8
9
本地/WebIDE 写 Markdown
    ↓ git push
Coding 私有仓库 (source/_posts/*.md)
    ↓ Jenkins Pipeline 触发
hexo clean → hexo generate → hexo deploy
    ↓ hexo-deployer-ali-oss
阿里云 OSS (misaka10013 bucket, 香港区)
    ↓ CDN + CNAME
https://misaka10013.cn

方案选型

方案 平台 免费额度/月 迁移难度 推荐度
方案A CNB云原生构建 (cnb.cool) 160核时（公测1600核时） 中等 最推荐
方案B GitHub Actions 2000分钟 较易 次推荐
方案C 本地直接推 免费 最易 兜底

选择CNB的理由：

  1. 腾讯生态同源：从Coding到CNB路径最顺，账号体系通用
  2. 公测额度极其充裕：1600核时/月，Hexo每次构建1~2分钟，够用800次
  3. 支持WebIDE：以后可以直接浏览器写博客
  4. 私有仓库安全：配置文件里的密钥不会暴露

迁移步骤

1. 创建CNB仓库

在 cnb.cool 微信扫码登录，创建组织（如 misaka10013），建立私有仓库 hexo-blog。

必须设为私有——_config.yml 里有阿里云 OSS 的 AccessKey。

2. 编写 .cnb.yml 构建配置

在仓库根目录创建 .cnb.yml：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
master:
  push:
    - docker:
        image: node:18
        volumes:
          - /root/.npm:cow
      stages:
        - name: 安装 Hexo CLI
          script: npm install -g hexo-cli
        - name: 安装项目依赖
          script: npm install
        - name: 清理旧构建
          script: hexo clean
        - name: 生成静态页面
          script: hexo generate
        - name: 部署到阿里云 OSS
          script: hexo deploy

几点说明：

  • image: node:18：使用Node 18官方镜像，Hexo在这个版本下最稳定
  • volumes: - /root/.npm:cow：缓存npm包，避免每次构建重复下载
  • 不需要逐条 npm install hexo-xxx --save，直接用 npm install 读取 package.json

3. 密钥安全：两种方案

方案一：私有仓库直接放明文（够用但不够好）

如果你确定仓库永远是私有的，_config.yml里的AK/SK可以保持不变。但有一个隐患——哪天误操作把仓库设公开，密钥全暴露。

方案二：CNB环境变量替换（推荐）

_config.yml 中使用占位符：

1
2
3
4
5
6
deploy:
  type: ali-oss
  region: oss-cn-hongkong
  accessKeyId: ${ALI_ACCESS_KEY_ID}
  accessKeySecret: ${ALI_ACCESS_KEY_SECRET}
  bucket: misaka10013

在 .cnb.yml 构建步骤中添加变量替换：

1
2
3
4
- name: 写入密钥到配置
  script: |
    sed -i "s/\${ALI_ACCESS_KEY_ID}/$ALI_ACCESS_KEY_ID/" _config.yml
    sed -i "s/\${ALI_ACCESS_KEY_SECRET}/$ALI_ACCESS_KEY_SECRET/" _config.yml

CNB的Secret变量在仓库设置中配置。

4. 推送源码

1
2
3
# 在博客源码目录
git remote add cnb https://cnb.cool/misaka10013/hexo-blog.git
git push cnb master

推送后CNB自动触发构建 → hexo generate → hexo deploy → OSS更新 → 域名生效。

踩坑记录

坑1：hexo-util 1.9.0 导致生成文件全为 0KB

症状：

CNB构建成功后，网站白屏。查看OSS文件列表，所有HTML文件大小均为0KB。本地 hexo generate 同样全部0KB。

排查过程：

  1. 最初怀疑是OSS域名绑定/权限问题（403 AccessDenied），但文件本身就是0KB，排除
  2. 怀疑是侧边栏配置修改导致，还原配置后问题依旧，排除
  3. 回退到旧版代码，问题仍然存在，说明不是代码问题而是环境问题
  4. 在 node_modules/hexo/lib/plugins/console/generate.js 注入调试日志
  5. 发现关键线索：hashRaw=Buffer(20) cacheData=Buffer(0) —— HashStream 正常工作但 CacheStream 返回空 Buffer

根因：

hexo-util@1.9.0 的 CacheStream 在 Node 18+ 下有bug，getCache() 返回空 Buffer，导致所有生成的静态文件内容为空。

解决：

1
npm install hexo-util@1.9.1 --save

升级后 hexo generate 正常输出621个文件，index.html 65KB。

教训：

  • Node版本升级可能导致依赖库的隐性bug暴露
  • 0KB文件排查要先确认是生成阶段的问题还是传输阶段的问题
  • npm install 读取的是 package.json 里的版本约束，^1.9.0 这样的语义化版本会自动拉取最新的1.9.x，所以 npm install 会拉到有bug的1.9.0；解决方法是在 package.json 中固定版本 "hexo-util": "1.9.1" 或在构建前显式升级

坑2：Coding Jenkins Pipeline 与 CNB 的语法差异

Coding使用的是Jenkins Pipeline语法（Groovy DSL）：

1
2
3
4
5
6
7
8
9
10
11
12
pipeline {
  agent any
  stages {
    stage('构建') {
      steps {
        sh 'git clone ...'
        sh 'npm install -g hexo-cli'
        ...
      }
    }
  }
}

CNB使用的是YAML声明式语法：

1
2
3
4
5
6
7
master:
  push:
    - docker:
        image: node:18
      stages:
        - name: 构建
          script: npm install

差异要点：

  • CNB不需要 git clone，源码已经自动检出在工作目录
  • CNB用 docker.image 指定运行环境，而非Jenkins的agent
  • CNB的stages是线性执行的列表，逻辑更简单

坑3：package.json 里依赖安装方式

Coding的Jenkins Pipeline里是逐条 npm install hexo-xxx --save，但直接改用 npm install 一次性读取 package.json 更高效。注意 package.json 里要去掉不需要的依赖（如 hexo-deployer-git），保留阿里云OSS部署所需的 hexo-deployer-ali-oss。

坑4：分支名要匹配

.cnb.yml 中的 master: 对应触发分支。如果你的默认分支叫 main，需要改为 main:，否则push后不会触发构建。

最终工作流

1
2
3
4
5
6
7
8
9
10
11
12
13
14
本地/WebIDE 写 Markdown
    ↓ git push
CNB 私有仓库
    ↓ .cnb.yml 自动触发
Docker (node:18)
    → npm install -g hexo-cli
    → npm install (含 hexo-util@1.9.1)
    → hexo clean
    → hexo generate
    → hexo deploy
    ↓ hexo-deployer-ali-oss
阿里云 OSS
    ↓
https://misaka10013.cn

总结

从Coding迁移到CNB，核心工作就是三件事：

  1. 把Jenkins Pipeline翻译成.cnb.yml——语法不同但逻辑一致
  2. 处理密钥——私有仓库可以直接放，但用Secret变量更安全
  3. 盯住依赖版本——Node 18下 hexo-util 1.9.0 的0KB bug是最隐蔽的坑

迁移完成后，CNB的构建速度和稳定性都比Coding更好，公测期间的免费额度对个人博客来说完全够用。唯一的遗憾是Coding上的WebIDE体验更好些，但CNB也在快速迭代中。

-------------本文结束感谢您的阅读-------------