使用 GitHub Pages 可以很方便的将静态网站部署到公网，Hugo 生成的静态博客也同样适用。 不过，每次都手动将网站代码 push 到运行 GitHub Pages 的仓库，虽然操作不麻烦但未免也太重复枯燥， 而通过 GitHub Actions 可以有效减少重复工作，提高工作效率。

事前准备

首先，明确我们的自动化逻辑：

确定博客源码的获取源

首先要让 GitHub Actions 能够获取博客源码，也就是 Markdown 文件，通常用 GitHub 仓库即可。

另外，有的博主也许并不想直接或间接地暴露 Markdown 源文件…… 虽然没尝试太多，理论上，获取源也可以是其他平台的代码仓库，甚至是自己的 SFTP 服务器。 只要你有能够安全访问它的方式即可，这里为了稳妥，只讲源码存储在 GitHub 仓库的情况。

确定构建时机

如果获取源是 GitHub 仓库，通过 push, pull_request 等操作触发构建则相当容易。

但如果是其他平台的仓库或者SFTP，GitHub Actions 也许不能够及时捕获到源码的变更， 但是通过定时运行 Actions 的方式也可以在一定程度上做到自动化构建·部署。

Note: 当然，也许别的平台也支持类似 GitHub Actions 一样的功能，那直接在该平台创建自动化脚本即可，比如 Huwwei Cloud。

创建 Personal access tokens

下面的脚本中涉及到 commit, push 操作，需要 GitHub 仓库的访问权限， 为了将相应的权限安全地赋予 GitHub Actions，需要用到 Personal access tokens。

选择右上角头像 - Settings - Developer settings - Personal access tokens， 点击 Generate new token

Note 随便填，自己能分清是什么就好。 然后勾选 workflow 和 admin:repo_hook，勾选 workflow 会强制勾选 repo， 所以最终创建的 token 将拥有 repo, workflow 和 admin:repo_hook 权限。

新建 workflow

Note: 至于为什么这里名字变成了 workflow，我也不是很明白。

个人理解是： GitHub Actions 只是 GitHub 提供的这个功能的名字； 这个功能中真正配置、运行的东西叫做 workflow(工作流)； 而每个 workflow 中运行的就是经常听到的 job。

感觉有点像 activity 或者说是 BPMN 项目的意思。

通过 GitHub 网页

在 GitHub 仓库页选择 Actions 标签，点击 set up a workflow yourself 新建 workflow。

通过本地手动创建

workflow 其实是在当前仓库当前分支下创建 .github/workflows/ 目录，在该目录下创建 .yml 文件，每个 .yml 文件就是一个 workflow 的配置文件。

Windows 不能直接创建 . 开头的目录/文件，可以参考以下命令：

1
2
3

cd "<path_to_blog>"
mkdir ".github\workflows"
echo "" > ".github\workflows\main.yml"

编写配置文件

以下是根据我的仓库整理的配置文件，可以按需要修改。

Note:

  • master 分支运行着 GitHub Pages
  • blog 分支存放着 markdown 文件
  • blog 分支的 themes/nicesima 目录是 submodule，链接到 niceRAM/nicesima 这个仓库。
 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
56
57
58
59
60
61
62
63
64

# workflow 的名字
name: Blog Build

# 触发 workflow 运行的事件
on:
  # 执行 push 时触发
  push:
    # 指定当 blog 分支被 push 时才触发。可以指定多个分支，可以省略，默认为 master
    branches: [ blog ]
  # 执行 pull_request 时触发
  pull_request:
    # 指定当 blog 分支执行 pull_request 时才触发。可以指定多个分支，可以省略，默认为 master
    branches: [ blog ]

  # 看原注释的意思，如果存在 workflow_dispatch，当前 workflow 允许被手动执行。
  # 但是我尝试的时候，如果存在这个设置，上面配置的事件将不会被触发，也就是只能手动执行。
  # workflow_dispatch:

# 环境变量
env:
  # GitHub 用户名
  GH_USERNAME: your_github_id
  # commit 时使用的 Email
  GH_EMAIL: [email protected]
  # 部署 GitHub Pages 的仓库，格式：用户名/仓库名
  GH_REPO: your_github_id/your_markdown_github_repo
  # 部署 GitHub Pages 的仓库的分支名
  GH_BRANCH: master
  
# 一个 workflow 由至少一个 job 组成
jobs:
  # jobs 的第一个子项是 job 的名字  
  build-deploy:
    # 该 job 的容器环境    
    runs-on: ubuntu-latest

    # 一个 job 由至少一个 step 组成，每个 step 以数组的形式依次编写    
    steps:
      # 拉取 markdown，也就是当前仓库的源码
      - uses: actions/checkout@v2
        with:
          # markdown 所在分支是 blog
          ref: blog
          # 同时拉取 submodule，因为要用到对应的主题
          submodules: true
          fetch-depth: 1

      # 引用 jakejarvis/hugo-build-action 构建网站代码
      # 当然也可以用其他的 Actions 甚至可以自己写，只是用法有点区别而已，思路都大同小异
      - name: Hugo Build
        uses: jakejarvis/[email protected]
        with:
          args: --minify
          
      # 引用 peaceiris/actions-gh-pages 将网站代码 commit 并 push 到 GitHub Pages 仓库
      # 同上，也可以用其他的 Actions，也可以全部自己写。
      - name: Deploy
        uses: peaceiris/actions-gh-pages@v3
        with:
          # 指定前面准备的 token
          personal_token: ${{ secrets.BLOG_DEPLOY_TOKEN }}
          PUBLISH_BRANCH: master
          PUBLISH_DIR: ./public
          commit_message: ${{ github.event.head_commit.message }}

至此 workflow 就编写完成了，如果是在网页端编写，最后别忘记点 Start commit 保存配置文件。

主要操作基本都在 steps 里，详细可以参考 官方文档。 在网页端编写时还可以在右侧的 Marketplace 随时搜索需要的 workflow。

测试 workflow

上传一篇文章或随便做点更新并 push，现在打开刚才的 Actions 标签，不出意外就可以看到 workflow runs， 也就是 workflow 的运行记录。

如果 workflow 运行出错，GitHub 还会发邮件通知，所有 runs 都可以查看完整日志和 workflow 配置文件， 对问题定位有很大帮助。

相关文章

参考链接