前言

之前的账号密码找不到了，恰好想要尝试一下久闻大名的 github action + netify，那就整一个吧

基本流程

  • 参照 hexo 官方文档构建一个 blog repo 推送到 github
  • 利用 action 执行构建，并部署到 github 的另一个 repo ，例如 blog-static
  • 在 netify 关联到blog-static，拉取文件并正式部署

对应的 action 文档

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
# This is a basic workflow to help you get started with Actions

name: CI

# Controls when the action will run. Triggers the workflow on push or pull request 
# events but only for the master branch
on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

# A workflow run is made up of one or more jobs that can run sequentially or in parallel
jobs:
  # This workflow contains a single job called "build"
  build:
    # The type of runner that the job will run on
    runs-on: ubuntu-latest
    
    strategy:
      matrix:
        node-version: [12.x]

    # Steps represent a sequence of tasks that will be executed as part of the job
    steps:
    # Checks-out your repository under $GITHUB_WORKSPACE, so your job can access it
    - uses: actions/checkout@v2
    - name: Checkout submodules
      uses: textbook/git-checkout-submodule-action@2.1.1

    # Runs a set of commands using the runners shell
    - name: Run a multi-line script
      run: |
        echo Add other actions to build,
        echo test, and deploy your project.
    - uses: actions/setup-node@v1
      with:
        node-version: ${{ matrix.node-version }}
    - name: install hexo
      run: |
        npm i -g hexo-cli
        npm i
    - name: set up git 
      run: |
        git config --global user.email "you@example.com"
        git config --global user.name "hexo-action"
    - name: deploy
      env:
         GITHUB_TOKEN: ${{ secrets.HEXO_TOKEN }}
      run: |
        hexo g
        hexo d

流程相当简单，不过话虽如此。过程中还是遇到了一些问题

遇到的问题

config 配置

我在 windows 上配置 ssh ，一直无法正确连接 GitHub，搞了半天发现是因为我曾经部署过多个 ssh key ，也包括多个 github 或者类似网站的 ssh 结果 ssh 不能正确的匹配 ssh key 和对应的域名

解决方法

因此，如果有多个 ssh 的话，需要配置 ssh config 来指定域名和 ssh key 的关系解决这个问题

1
2
3
4
5
6
7
8
9
Host github.com
    HostName github.com
    PreferredAuthentications publickey
    IdentityFile ~/.ssh/id_rsa
    
Host github.com
    HostName github.com
    PreferredAuthentications publickey
    IdentityFile ~/.ssh/id_rsa_other

这样 ssh key id_rsa 和 id_rsa_other 都会匹配到 github 的域名下，从而正确的连接对应的 repo

action 推送到其他 repo

然后遇到的另一个问题，就是如何将 action 构建好的文件推送到另一个 repo

正常来说，当然就是得到对应 repo 的权限，比如单个 repo 的 Deploy Keys,又或者用户的个人 token 都是可以的，然后再 action 按照正常 nix 下设置 ssh 可以 然后命令行 git push 即可

不过， 因为这里用到了 hexo ，可以执行 hexo d 的时候通过读取 config 中的配置自动推送，因此绕了一些

ps hexo 推送到 git 用到了对应的插件 hexo-deployer-git 记得要安装

解决方法

参照这个 https://github.com/hexojs/hexo-deployer-git/issues/159

不能直接根据文档简单的设置

1
2
3
4
5
6
7
8
deploy:
  type: git
  repo: https://github.com/<myusername>/<myrepo>.git
  branch: gh-pages
  token: $GITHUB_TOKEN
  name: <my "visible" name>
  email: <my email>

而需要

1
2
3
4
5
6
7
8
9
deploy:
  type: git
  repo:
    github:
      url: https://github.com/<myusername>/<myrepo>.git
      branch: gh-pages
      token: $GITHUB_TOKEN
  name: <my "visible" name>
  email: <my email>

这样 github token 才能正确生效，action 里面如何配置 token 到环境变量可以看上面的 action

github action or gitlab ci

说实话，GitHub 如此之久才推出自家的 cicd 工具，还是让我觉得很好奇的，因为此时不仅有 Travis CI 之类的专门 ci 工具，甚至 gitlab 也都早早的出台自家整合的 cicd 工具。

而 gitlab ci 或许是大多数使用 gitlab 作为公司自建 git 服务，用的最多 ci 工具了

详细的对比可以看看这个网站 https://knapsackpro.com/ci_comparisons/github-actions/vs/gitlab-ci

就我个人简单使用体验而言有以下的非常明显的点

gitlab 描述语法，功能更加全面

gitlab 因其发展时间较久，对于 ci cd 任务的表述语法，功能上更加丰富

比如，gitlab ci 支持根据特殊 commit message 触发任务，而 github 目前还只是支持分支，事件级别的出发机制

github 的可封装抽象 action， 与第三方 action

actions 虽然在功能语法上弱于 gitlab（目前来看），但是有一个非常具有特色而强势的功能，通过 uses 语法使用高度抽象和封装的 action 组件。

比如上文中我就用到了多个抽象 action：

1
2
3
- uses: actions/setup-node@v1
  with:
    node-version: ${{ matrix.node-version }}

其功能正如其名，这个 action 用于设置 node 环境。具体的文档参见 https://github.com/actions/setup-node

这些 action 有别于主流程通过 yaml 描述功能，在 action 可以通过编程的方式，实现你所需要的功能。

而且可以从 https://github.com/actions 和官方教程中就可以看到，实际上 actions 当中非常多的功能都是通过官方维护的 action ，抽象封装实现，而非 gitlab 那样通过官方语法支持 。

此外除了可以使用官方的 action 集合之外，当然也可以使用其他用户开发的第三方 action 来完成任务流程的编排，非常契合 github 开源拖拉机的精神

但是

但是，开源拖拉机之所以是开源拖拉机，必然不都是好事。

稍微简单想想就可以知道，在自己的github action 流程中插入第三方封装的 action，相当于提供一个机会读取到配置各种重要的 token。

且不说，第三方 action 理论上是可以对你的流程上下其手的。

当然，这也是开源的风险之一，也没有必要因噎废食。

说好的模块可视化界面呢？

最后，就是我这次使用的时候印象还停留在 github action 刚出来那个酷炫的图形化界面拖拉编排的样式上。

没想到实际使用的时候，就已经是 yaml 声明式编写方式。还是有点失落的。

当然，图形化编排固然炫酷，但是毕竟 yaml 声明式是一个发展了更久，用户也更加熟悉的方案，这个选择情有可原。

只是谁不喜欢看起来炫炮的东西呢？

优化点

这次实际还只是简单的使用了官方 demo 去编排。还有好几个可以优化的地方

  1. 精简 aciton 文件，保留必要的部分
  2. 构建 cache，在我的使用场景中，显然 npm package 和 hexo 构建结果都是可以考虑缓存，提高运行速度的，毕竟不是每次安装依赖和完全构建
  3. 根据命令触发 build，有的时候只想通过 git 同步文件，并不需要构建，准备自己写第三方 action 试试。

总结

这篇文章就是简单的记录一下迁移的过程和看法，总体而言这个 action + netify 方案确实很舒服。

而且现在还有很多其他类似的 saas 服务，这方面的基础建设真是越来越好用了。