自从 2017 年使用 Hexo+NexT 作为博客框架以来，已经过去好几个年头。就如前面那篇hexo使用Artalk评论系统 博客所言，由于 Alliot 之前对 NexT 主题与部分插件做了许多侵入式的魔改，基本没有对其做过日常的版本升级维护，因此，已经没有平滑升级的可能性。在一次插件失效的契机下，终于下定决心推倒重建。 本文记录了这一次重建的过程以及在维护模式上相比旧版本的改进。

我们知道 Github Pages 是 Github 免费提供给用户展示页面的一项服务。当我们完成项目开发后，想将页面部署到 Github Pages 时，该要怎么操作呢？

可以在 GitHub 的储存库设置中设置用于展示页面的分支，该分支只保留构建后的静态资源，也就是源码与编译后的静态资源分离。按照传统的做法是：手动运行编译命令，编译后再复制到指定分支中。这样操作很繁琐，但使用 Travis CI 持续集成服务之后就可以不用操心这些事了。

概念

既然我们要使用 Travis CI，首先得搞清楚人家具体是干嘛的吧？

Travis CI 是一个 **持续集成(Continuous integration, CI)**。它与 git 相耦合，每当有 commit 提交时，它将自动触发构建与测试。若运行结果符合预期，才将新代码集成到 主流(mainline) 中，这样使应用更加健壮。

值得注意的是，Travis CI 提倡每次 commit 都是独立较小的改动，而不是突然提交一大堆代码。因为这有助于后续构建失败时可以回退到正常的版本。

运行构建时，Travis CI 将 GitHub 存储库克隆到全新的虚拟环境中，并执行一系列任务来构建和测试代码。如果这些任务中的一项或多项失败，则将构建视为已损坏。如果所有任务均未失败，则认为构建已通过，Travis CI 会将代码部署到 Web 服务器或应用程序主机中(在本文中是指 Github Pages 服务)。

准备

在使用之前，需要准备一个 Github 的账号对 Travis CI 进行授权。

1. 接着通过 Github 的账号登录 Travis CI，点击 SIGN IN WITH GITHUB。
2. 点击后会被重定向到 Github 进行授权。
3. 授权后，若是第一次登录的话会被重定向至引导页:
4. 点击引导页第一步的按钮，使用 GitHub Apps 激活储存库。可以选择给全部储存库都激活，也可以激活指定储存库。本文以 <username>.github.io 为例:

   注意: 这个 username 是你自己的 Github 用户名。笔者的 username 为 anran758 那储存库的名字就为 **anran758.github.io**。

5. 激活后会被重定向到设置页，点击待部署的储存库右侧的 setting 按钮，跳转至 Travis CI 储存库设置页。我们需要在此页设置部署 Github Pages 时所需的环境变量:

环境变量的值需要从 Github 拿拥有部署权限的 token:

1. 打开 Github，点击头像，再点击 Settings 进入设置页：
2. 进入设置页面后在左侧边栏点击开发者设置:
3. 跳转后在左侧边栏点击 Personal access tokens, 然后在头部点击 Generate new token:
4. 填写 token 备注、权限，最后点击生成 token:
5. 生成 token 后点击复制按钮，复制到粘贴板: 注意要妥善保管好 token，重新刷新页面后这个 token 将不会再展示出来。如果忘记了 token 的话，也只能在 token 编辑页中重新生成。这会导致所有用到该 token 的应用都要更新值。 比方说有三个应用使用了该 token，重新生成后只在一个应用更新的值，那其他两个应用不更新就无法使用了。
6. 复制 token 后切回 Travis CI 储存库的设置页，添加环境变量:

这样我们的准备工作就完成的差不多了。

配置

在项目目录中新建文件 .travis.yml，内容如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

language: node_js
node_js:
  - lts/*

install:
  - yarn install # npm ci
script:
  - yarn test # npm run test
  - yarn build # npm run build

deploy:
  provider: pages
  local_dir: dist
  target_branch: master
  on:
    branch: develop
  token: $GITHUB_TOKEN
  skip_cleanup: true
  keep_history: true
  committer_from_gh: true

由于 webpack 项目依赖 Node.js，因此语言(language) 设置为 node_js，同时还指定使用最新的 LTS Node.js 版本(lts/*)。

install 是安装部署所需的依赖项，script 则是用于运行测试或构建脚本。他们都是 Travis 的工作生命周期(Job Lifecycle)必触发的钩子(阶段)。

install 钩子若有脚本/命令运行失败的话，整个构建会停止。而 script 钩子表现则不同，当有脚本/命令运行失败后虽然构建会失败，但还会继续执行后面的脚本。如 yarn test 运行失败后会继续跑 yarn build 命令。

以下是 Travis CI 主要的阶段流程图:

graph TDA[before_install] --> B[install]A & B -.-> Z((停止构建))B --> C[before_script]C --> D[scrip]D --> E(after_success)D --> F(after_failure)E & F --> G[before_deploy]G --> H[deploy]H --> I[after_deploy]I --> J[after_script]

部署

通过 deploy 可以指定部署方式，下面将逐个介绍部署所用的选项：

provider 是部署类型。现在我们想将页面部署到 Github Pages，那就需要将 provider 设为 pages。

local_dir 指定要推送到 Github Pages 的目录，默认为当前目录。webpack 默认的输出目录是 /dist，因此需要将值设为 dist。除此之外，Travis CI 默认情况下会删除构建期间创建的所有文件，因此需要设置 skip_cleanup: true 保留构建出来的 dist 目录.

若 on.branch 有 commit 提交的话，Travis CI 将从 on.branch 分支运行编译脚本，编译后会把 local_dir 目录强制推送到 target_branch 中。(target_branch 默认值为 gh-pages)

现在我们要部署的储存库是 <username>.github.io。这种类型的储存库有些特殊——它只能在 master 分支展示构建后的代码，而不能修改为其他分支。在 GitHub 储存库的 Settings 中的 Source 选项可以看到详细信息:

然而其他储存库则没有这种限制:

因此要部署到 <username>.github.io 储存库的话，target_branch 只能设为 master，触发编译的 on.branch 分支则可以自己定义。

其他储存库可以按照标准流程来开发：

• develop 作为开发分支
• master 作为主分支
• gh-pages 作为页面展示分支

等功能开发并测试完毕后，将 develop 的代码合并到 master 分支并推送至远程。Traivis CI 检测到 matser 有 commit 提交后会自动运行脚本构建，构建完毕后将输出目录推送至 gh-pages 分支。

当然 Github Pages 也不是随便来一个人就可以部署的，你想要部署到储存库中首先得有该储存库的操作权限吧？token 就是证明你身份的东西。在上文中我们预先设置好了一个名为 GITHUB_TOKEN 的环境变量，此处我们可以通过 $GITHUB_TOKEN 直接取出该环境变量的值即可。

其他还有一些细节问题可以调整：比如推送构建后的代码到 target_branch 时使用的是强制推送(git push --force)，如果你觉得这种强制覆盖历史记录的方式有点暴力的话，可以设置 keep_history: true 来保留提交记录。

自动部署后 commit 提交者默认是 Travis CI 的信息。也可以设置 committer_from_gh 允许 Travs CI 使用令牌所有者的个人信息来提交 commit。

配置完毕后现在只需将 .travis.yml 提交到远程，Travis CI 就开始工作了：

甚至还可以在 Github commit 信息中看到编译的情况:

如果构建出问题的话，Travis CI 还会发邮件提示你:

部署成功后就可以直接通过浏览器访问啦~ 储存库部署的是 <username>.github.io 的话，访问链接为 https://<username>.github.io/。其他储存库可以访问 https://<username>.github.io/<repoName>。

比如笔者的主页与博客是两个项目分离的，部署后的链接地址为 https://anran758.github.io 和 https://anran758.github.io/blog。

Travis CI CLI

还可以通过 Travis CI CLI 来进行操作:

按照文档的 Installation 部分安装 Travis CI CLI。

安装完毕后通过命令行进入储存库目录，输入 travis -v 来检查是否安装成功。

Travis CI 有两个不同域名版本的 API，一个是 .com 新版本，.org 是旧版本的。先确定自己使用的是哪个平台，再设定它:

1
2
3
4
5
6
7

# 默认是 .org
travis endpoint
# API endpoint: https://api.travis-ci.org/

# 笔者使用的是 .com 的平台，因此需要修改默认的模式。设置 `--com` 和 `--pro` 的效果是相等的。
travis endpoint --com --set-default
# API endpoint: https://api.travis-ci.com/ (stored as default)

确定版本后输入 travis login 或 travis login --pro 进行登录。Mac os 系统可能会遇到 Travis Ci CLI 依赖的 ruby 版本和系统自带 ruby 有冲突：

1
2
3
4
5
6
7
8
9
10
11

travis login --com
# We need your GitHub login to identify you.
# This information will not be sent to Travis CI, only to api.github.com.
# The password will not be displayed.

# Try running with --github-token or --auto if you don't want to enter your password anyway.

# Username: anran758
# Password for anran758: ***********
# Unknown error
# for a full error report, run travis report --pro

若不想处理这些麻烦的依赖问题，可以在 Travis CI 的个人设置页 复制 access_token 到 ~/.travis/config.yml 的配置中:

1
2
3
4

# code ~/.travis/config.yml # 通过 vscode 进行修改

# 通过 vim 进行修改
vim ~/.travis/config.yml

修改 endpoints 下的 access_token 并保存后，在命令输入 travis accounts --pro 检查是否成功:

1
2
3
4

travis accounts --pro
# travis accounts --pro
# anran758 (Anran758): not subscribed, 18 repositories
# To set up a subscription, please visit travis-ci.com.

这样就登录完毕啦~ 接着在输入 travis logs 就可以查看日志：

1
2
3
4
5

# 查看最新构建的日志
travis logs

# 查看指定构建日志
travis logs 2

还可以清空指定构建的日志:

1
2

# travis logs 2 --d # -d 简短选项
travis logs 2 --delete

参考资料:

• Creating a personal access token for the command line
• GitHub Pages Deployment
• Job Lifecycle