利用 Gitlab CI 持续集成部署 Hexo

使得命题“多终端管理 Hexo ”为真命题

前言

之前说过一下，我先后抛弃了 Wordpress 和 Typecho （即使再小，也是要 SQL 的……→ → ）
现在投奔到了 Hexo 。不可不说， Hexo 是个好东西，不过我是觉得突然没了后端，多终端的更新是个问题。例如我现在想更新一个文章，我必须在一个安装了 Hexo 并且安装了 Material 主题的电脑上更新（(╯‵□′)╯︵┻━┻）。这个大大限制了我的更新自由度，所以研究如何多终端更新是非常非常非常非常非常*N 有必要的。

所幸，最近从 Google 了解到了 Hexo 的远程部署，大概有两种实现方法

• Hexo-Admin 插件 ：通过安装 Hexo-Admin插件，获得类似后端的界面。用户通过该页面进行博客的更新。但显然，该方案需要一台独立服务器

• CI 自动构建 ：通过 CI 自动构建。仓库收到更新后， CI 收到通知并执行构建， git push 到远端

什么是 CI

持续集成 ( Continuous integration,简称 CI )　
在软件工程中,持续集成是指软件开发流程中一系列的最佳实践,近几年已被广发应用到实际项目开发中。极限编程中一项建议实践便是持续集成，它提供了及时发现问题、追踪问题、修复问题的机制，替代了传统的在所有代码编写完毕后才提交QA部门进行测试的方法。持续集成对单元测试较为依赖，测试覆盖率越高，单元测试越准确，越能体现持续集成的效果。——智库

该方案的来源

由上文，显然， CI 就是可以理解为每次push或者merge代码后，自动构建生成的一种工具。基于这个，我们是不是可以创建一种专门用于发布 Hexo 的 CI 呢？
受到 neo喵 的使用 Gitlab CI 实现 Hexo 持续部署 启发，有了这个方案。

原文提到，neo喵 是用 Gitlab 集成的 CI 完成的，他博客使用的是 FTP Deploy ，所以整体实现流程稍微没那么复杂，而本文主要介绍 Gitlab CI 如何更新博客到 Github / Coding pages 。

Gitlab 使用体验

的确如世人所讲，相对于 Github 的收费私有仓库（据说学生免费？？！！），Gitlab 的私有仓库体验非常优秀，且得益于其开源特性，可以搭建在自己的 VPS 上。
Gitlab CI 也与 Repository 高度集成，可以自由方便地配置使用
另外，我是将博客文件 git pull 到了 Coding 的私有库上，并与 Gitlab 保持同步。

虽然每次用的时候，总会想起使用rm rf删库跑路，并在 Youtube 上直播，创立了世界备份日

准备工作

在 Gitlab 建立一个私有仓库。并在 Repository 中，添加一个 Gitlab 的 Origin 远端 ，然后将 Hexo 的文件（含 Hexo 主文件，主题文件，插件 ） git push 到私有仓库上
那么， Gitlab 上就存放了博客的工程文件，可以进入下一步。

• 请在.gitignore文件中去除对 node_modules ，db.json ，package.json 的忽略，无论是 Hexo 根目录或是主题目录均如此处理

Gitlab 配置

本节分为两部分

• Workflow 编写
• Gitlab 与 Coding 的 SSH 连接 （若用 FTP 方式发布，可无视）

Workflow 编写

Gitlab CI 与所有常见的 CI 类似，如 Jenkins 和 Travis.CI 等，需要一个脚本，引导 CI 执行操作。这里我们在根目录新建一个.gitlab-ci.yml，这样就可以让 CI 自动执行部署。

我们在.gitlab-ci.yml中输入以下内容

image: node:6.6.0
pages:
  cache:
    paths:
    - node_modules/

  script:
  - npm install
  - npm install hexo-cli -g
  - hexo deploy
  artifacts:
    paths:
    - public
  only:
  - master

若要了解该脚本的原理，请查阅 Neo喵 使用 Gitlab CI 实现 Hexo 持续部署 及 Gitlab CI Wiki

• 这是利用 FTP 发布所需编写的，若你使用 Git 方式发布到 Github / Coding pages ，请继续往下看
• 使用 FTP 发布，请将工厂文件存储在私有库中，避免 FTP 账号的泄漏

Gitlab 与 Coding 的 SSH 连接

本节只是一个引子， SSH 相关操作都可以参照 Gitlab CI Wiki 处理

部分使用 Hexo 的用户不一定拥有虚拟主机或 VPS ，并通常使用 Github / Coding pages 服务支持运行

Gitlab 在此处做得非常好，可以采用环境变量方式添加 SSH 密钥，灵活而安全

在Gitlab Wiki中，我们看到

Create a new Secret Variable in your project settings on GitLab following Settings > Variables. As Key add the name SSH_PRIVATE_KEY and in the Value field paste the content of your private key that you created earlier
Next you need to modify your .gitlab-ci.yml with a before_script action. Add it to the top

由此，我们知道，我们需将我们的 SSH公钥 添加到你所使用的 Pages 远程仓库中，然后进入 Gitlab 的私有库项目中， Settings > CI/CD Pipelines > Secret Variables **中，添加一个 **Key 为Secret Variables， Value 即为你的 SSH 私钥

配置好环境变量，我们继续配置 SSH 的连接。我们在.gitlab-ci.yml中添加一段before_script，注意添加添加在前节中脚本的头部，并在script中添加 Git 账户的配置

例如

before_script: 
  - 'which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )'
  - eval $(ssh-agent -s)
  - ssh-add <(echo "$SSH_PRIVATE_KEY")
  - mkdir -p ~/.ssh
  - '[[ -f /.dockerenv ]] && echo -e "Host *\n\tStrictHostKeyChecking no\n\n" > ~/.ssh/config'
  
image: node:6.6.0
pages:
  cache:
    paths:
    - node_modules/

  script:
  - npm install
  - npm install hexo-cli -g
  - git config --global user.email "Email-address@example.com"
  - git config --global user.name "Username"
  - hexo deploy
  artifacts:
    paths:
    - public
  only:
  - master

• 按照此例，修改 Git 的用户名及邮箱地址， Gitlab CI 与 Pages 仓库的 SSH 连接就已经配置成功了。

现在我们可以尝试push或merge一些微小的修改，让 Gitlab CI 为我们自动部署。具体执行结果，可以在pipeline中查看，并且无论执行成功与失败，均会通过邮件通知你。

小结

本文介绍了利用 Gitlab CI 进行 Hexo 的持续部署 ，并主要介绍了 SSH 连接 Origin 远端仓库，进而进行 Hexo 的 Git 部署发布。以后只要将文章push或merge到 Gitlab 的仓库，就可以实验自动部署发布。
优点如下：

• 随时随地，何时何地更新你的博客
• 目前使用免费
• 高度集成的 Gitlab CI 与 Repository ，无需再另外配置第三方 CI 平台
• 安全，不易泄露 FTP 账户及 SSH 私钥

我将 neo喵 的 HexoAutoBuildScript— neoFelhz 项目 fork 到了我的仓库中，并针对 SSH 做出了如上的处理，并放在ssh-link分支。附上地址 HexoAutoBuildScript— Kitcham
当然他的 HexoAutoBuildScript— neoFelhz 项目上也已经有一个专门的ssh_config去实现针对 Github 和 Coding 的 SSH 配置，大家可以去参考下