迁移 Hexo 渲染环境至 GitHub Actions
本博客使用的是 Hexo 静态博客框架,我将渲染环境搭建在家中 NAS 之上,部署了一个 Ubuntu Docker 并安装好了 Node.js 环境,正常使用了一两年。
上周末,写完新文章的我心血来潮,打算在更新博客的时候顺便更新一下老旧的 Node 和 Hexo(Node 12, Hexo 5.2)。
一番折腾之后,以 npm 和 hexo 环境全部被破坏(事后想想也许只是环境变量掉了)的下场结束。
鉴于 NAS 性能低下,更新一次 node module 都需要 30 分钟,我放弃了在 NAS 上重新部署渲染环境的念头,转而使用 GitHub Actions 渲染,并同时部署于 GitHub Pages 与 CloudFlare Pages。
将渲染环境迁至 GitHub Actions
不久之前,CloudFlare Pages 悄悄下架了 Hexo 框架的部署功能,只能用 GitHub Actions 渲染,然后再部署至 CloudFlare Pages 了。
项目结构的修改
若想使用 GitHub Actions,需要将博客的源码上传至 GitHub。考虑到隐私和安全的问题,建议创建一个私有仓库管理源码。
对于项目没有什么需要修改的,因为 Actions 渲染的流程和本地渲染的流程没有区别。
唯一需要改动的,是引入的主题。由于两个 Git 仓库不能嵌套,我们需要以 Git submodule 的形式引入主题仓库。
我使用的是 Fluid 主题。采用 覆盖配置 的方法,即在根目录之下有一份配置会覆盖主题内的配置文件,便于在 Actions 中渲染。
以下也将以 Fluid 为例,请根据你使用的主题修改命令或代码。
首先,删除原来的主题(若使用的是主题内的配置,注意备份配置文件!)
返回博客源码的根目录,执行:
1 |
|
末尾的 themes/fluid
为此 submodule 在项目中的位置与名字,与先前本地渲染时的配置相同即可。
删除子模块的过程较为繁琐,请参考网上的文章进行操作。
在 Clone 此项目时,submodule 默认不会被下载,需要使用指令:
1 |
|
下载 submodule。在下面会提到的 Actions 配置文件中会出现这条指令。
接着,就可以将博客源码上传至 GitHub。
GitHub Actions 相关文件
在博客源码根目录创建 .github/workflows/submit.yml
和 .github/script/blog-update.sh
两个文件,填入下列代码。
以下代码参考文章 GitHub Actions 自动部署 Hexo 博客到 cPanel 虚拟主机 - 谷中望月,有所修改。
submit.yml
:
1 |
|
.github/script/blog-update.sh
:
1 |
|
Commit + Push,打开 Actions 界面,就能看到正在运行的 Action 啦。
不出意外,Action 成功执行,1分钟内博客就能渲染成功、部署至 GitHub Pages。
同时部署至 CloudFlare Pages
步骤较为简单,我简述一下。
打开 CloudFlare Pages, 连接至存放 渲染后 的静态文件的仓库,渲染的框架选择 None,执行的指令填写 exit 0;
就可以了。
执行部署后,渲染后的静态文件就被部署至 CloudFlare Pages 啦。