关于hexo博客的github actions CI配置

本文最后更新于 2024年6月17日 凌晨

在之前的这篇博客: 将博客搬迁到upyun中主要讲了一下我把博客从github pages搬迁到upyun的配置过程。

其中包括了upx等工具的使用, 本文就不再赘述这些了。

放假了无聊又想摆弄一下博客,发现之前的博客的部署流程还是相对复杂,主要流程包括:

  1. 写文章
  2. 编译生成public
  3. 同步到github上
  4. 发布到upyun上

其中编译的时间尤其长, 并且伴随着文章, 图片的增加用时将只增不减。

采用 github actions预计的问题与解决

一直打算将部署流程放在github action上,但之前没有时间折腾这个,并且github action我当时想着会面临一个问题:

每次都需要配置环境的时间,也就是npm install安装大大小小的依赖, 安装upx依赖等, 都需要很多的时间, 而我们经常写博客是不看到发布页不罢休的, 所以在本地和在云端貌似并没有什么很大的区别, 云端CI反而会拖慢发布时间.

而今天我研究了一下, 发现了一个好用的东西: actions/cache

This action allows caching dependencies and build outputs to improve workflow execution time.

简单来说就是可以缓存github action时产生的一些构建的生成文件或者是网上down下来的依赖.

这样就完美解决了node_modules下载和upx工具下载消耗的时间问题

workflow文件

其他东西就不多说了, actions文件的语法也可以直接看github的官方文档: https://docs.github.com/cn/actions

这里把我最后的actions文件拿出来瞅瞅, 供参考

主要流程大概就是:

graph LR

A["缓存/下载node_modules"] --> B["hexo编译生成public文件"] --> C["缓存/下载upx"] --> D["upx将public下的文件上传到upyun"]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
name: 发布博客到upyun
on: push

jobs:
deploy:
name: Deploy
runs-on: ubuntu-latest
environment: upx

steps:
- name: Checkout
uses: actions/checkout@v3

- name: Cache node modules
uses: actions/cache@v3
id: cache-node
with:
path: node_modules
key: ${{ runner.os }}-node-${{ hashFiles('**/package-lock.json') }}
restore-keys: |
${{ runner.os }}-node-

- name: Install Dependencies
if: steps.cache-node.outputs.cache-hit != 'true'
run: |
npm i

- name: Hexo generate from source
run: |
npm i -g hexo-cli
hexo clean && hexo generate

- name: Cache upx
uses: actions/cache@v3
id: cache-upx
with:
path: upx-dir/upx-command-dir
key: ${{ runner.os }}-upx-upxCahce
restore-keys: |
${{ runner.os }}-upx-CacheBackUp-

- name: Install Upx
if: steps.cache-upx.outputs.cache-hit != 'true'
run: echo upx-cache-miss && mkdir upx-dir && cd upx-dir && wget https://github.com/upyun/upx/releases/download/v0.3.6/upx_0.3.6_linux_x86_64.tar.gz && tar -xf upx_0.3.6_linux_x86_64.tar.gz && mkdir upx-command-dir && mv upx upx-command-dir

- name: Login Upx And Post
env:
bucket: ${{secrets.BUCKET}}
operator: ${{secrets.OPERATOR}}
operator_password: ${{secrets.OPERATOR_PASSWORD}}
run: |
./upx-dir/upx-command-dir/upx login $bucket $operator $operator_password
cd public
../upx-dir/upx-command-dir/upx put ./ /

hexo deploy(可选)

由于我直接上传到了upyun, 所以略过了hexo deploy的配置

如果需要hexo deploy, 可以进行如下配置:

1
2
3
4
5
6
7
8
9
10
11
12
13
# ...
- name: Hexo Deploy
env:
priv_key: ${{secrets.PRIV_KEY}}
run: |
mkdir -p ~/.ssh/
echo "$priv_key" > ~/.ssh/id_rsa
chmod 600 ~/.ssh/id_rsa
ssh-keyscan github.com >> ~/.ssh/known_hosts
git config --global user.name ${{secrets.USER_NAME}}
git config --global user.email ${{secrets.USER_EMAIL}}
hexo deploy
# ...

也就是在虚拟机中将私钥放上去

具体的公钥和私钥配置应该在之前配置好, 配置于settings/SSH and GPG keys

push back(可选)

有时我们会遇到需要将代码回推送到仓库的需求

比如我正在使用一个插件: hexo-abbrlink

它的作用是根据title + date生成一个永久的文章id, 避免了文章标题有中文时link过长的问题, 优化了seo

但是这个插件会修改_post文件夹下的源代码, 所以需要我们将修改后的文件再次推送到github仓库

由于在上一步操作(hexo deploy)中我们已经将ssh的私钥保存了, 所以这里就不需要再配置了, 不过需要注意由于仓库不一定发生代码(如果文章不是第一次创建, 就不会生成abbrlink, _post文件夹也不会变更), 这时如果我们直接:

1
2
3
git add .
git commit -m "xx"
git push

就会在报working tree clean的问题, 这个workflow也会随即终止

于是我们需要加一个判断, 整理好的script如下:

1
2
3
4
5
6
7
8
9
#!/bin/sh

if [ -z "$(git status --porcelain)" ]; then
echo "nothing to update."
else
git add .
git commit -m "update: [abbrlink] blog source code update."
git push origin master
fi

关于hexo博客的github actions CI配置
https://moreality.net/posts/40160/
作者
Moreality
发布于
2022年8月12日
许可协议