关于hexo博客的github actions CI配置

在之前的这篇博客: 将博客搬迁到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"]

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, 可以进行如下配置:

# ...
      - 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文件夹也不会变更), 这时如果我们直接:

git add .
git commit -m "xx"
git push

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

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

#!/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