hexo部署到github上之后无法访问_Github 使用 Travis CI 实现 Hexo 博客自动部署

最新推荐文章于 2022-07-11 13:08:51 发布

weixin_39618176

最新推荐文章于 2022-07-11 13:08:51 发布

阅读量405

点赞数

文章标签： hexo部署到github上之后无法访问

想学一下 Travis CI 的用法，带着目的学习效果更佳。那么，我最终的目的就是实现 Github 上的Hexo 博客仓库有内容更新后，自动运行 Hexo 部署命更新博客。

Travis CI

Travis CI 在 Github 的 Marketplace 中可以看到，这是它 Marketplace 的链接:Travis CI

Continuous Integration，简称 CI：意思是，在一个项目中，任何人对代码库的任何改动，都会触发 CI 服务器自动对项目进行构建，自动运行测试，自动编译，甚至自动部署到测试环境。这样做的好处就是，随时发现问题，随时修复。因为修复问题的成本随着时间的推移而增长，越早发现，修复成本越低。

Travis CI 是在线托管的 CI 服务，用 Travis 来进行持续集成，不需要自己搭服务器。

官网对使用 Travis CI 有详细的使用步骤：

前往 Travis-ci.com and Sign up with GitHub.
接受授权
选择你想要使用 Travis CI 的仓库或者你也可以在 Github-settings-Applications-TravisCI-Configure 中去更新配置；
在你仓库怎增加 .travis.yml 文件，这个文件定义了构建的步骤，例如安装依赖等等。
将 .travis.yml 文件推送到你的远端仓库，然后就会触发 Travis CI 构建；
登录 Travis CI然后选择你的仓库查看构建任务的执行详情；

Job Lifecycle -- Job 生命周期

Travis CI 为每种编程语言提供默认构建环境和默认的阶段集。创建虚拟机为你的Job提供构建环境，将存储库克隆到其中，安装可选的插件，然后运行构建阶段。

job 的声明周期，主要包含两大部分：

install：安装依赖，官网有专门讲解的 Installing Dependencies
script：运行构建脚本；

在 installation 阶段之前（beofore_install）、在 script phase 之前（before_script）或之后（after_script），你可以运行自定义命令；

当构建成功或失败置换后，可以使用 after_success（例如构建文档）或 after_failure（例如上载日志文件）阶段执行其他操作（actions）。在 after_failure 和 after_success 中，您可以使用 $TRAVIS_TEST_RESULT 环境变量获取构建结果。

完整的 job 生命周期(包括三个可选的部署阶段，以及在检出 git 存储库和更改到存储库目录) 如下：

apt addons 可选安装
cache components 可选安装
before_install
install
before_script
script
before_cache (for cleaning up cache) 可选
after_success or after_failure
before_deploy 可选
deploy 可选
after_deploy 可选
after_script

一次构建任务可有许多 job 组成。

Install Phase

默认依赖项安装命令取决于项目语言。例如，Java 构建使用 Maven 或 Gradle，具体取决于存储库中存在的构建文件。

install: ./install-dependencies.sh

{% note success no-icon %} When using custom scripts they should be executable (for example, using chmod +x) and contain a valid shebang line such as /usr/bin/env sh, /usr/bin/env ruby, or /usr/bin/env python. {% endnote %}

你可以选择跳过安装依赖项阶段：

install: true

自定义构建阶段

Ruby 构建示例：

script: bundle exec thor build

可以定义多脚本命令：

script:
- bundle exec rake build
- bundle exec rake builddoc

这样的定义，如果第一行命令返回值非 0，并不会影响第二行命令的执行。但是最后的总结果是会标记为 fail 。

想要实现那种「串行」效果，可以这么写：

script: bundle exec rake build && bundle exec rake builddoc

更负载一点的构建命令，就将构建的步骤写到脚本文件中，然后：

script: ./scripts/run-tests.sh

构建中断

下面的四个阶段中，任意阶段中命令抛出非 0，构建都会被中断：

before_install
install
before_scrip
script

{% note warning no-icon %} 如下阶段的退出不会影响构建结果。但是，如果其中一个阶段超时，则构建将标记为失败：

after_success
after_failure
after_script
fter_deploy和 {% endnote %}

部署

部署是 job 生命周期中的可选阶段。这个阶段定义了使用持续部署方法去将你的代码部署到 Heroku, Amazon 或其他支持的平台。如果构建失败，那这一步自然会被跳过的。

将文件去部署时，通过将 skip_cleanup 添加到 .travis.yml 中，可以阻止Travis CI 重置您的工作目录并删除在构建期间所做的所有更改（类似于这个命令的效果 git stash --all）：

deploy:
  skip_cleanup: true

注意点：before_deploy 和 after_deploy 在执行每个部署任务时，都会被触发执行。

Build Stages

build stages 是一个将 job 分组的方法。在每个 stage 中平行的执行 job。但是如果一个 stage 执行失败，会影响到后续的 stage 执行。这不就是 pipeline 的模型吗？

在 stages section 定义 stages 的顺序：

stages:
  - compile
  - test
  - deploy

部署 Hexo 博客

Travis 准备

为了能够实现代码推送到 Github，需要给 Travis CI Github 的 Persional access tokens，在 settings- Developer settings 可以生成一个。

然后进入 Travis 中的项目设置界面，可以给具体的代码库进行设置，比如增加环境变量：

主要加了一个环境变量 GH_TOKEN，这个在后面的 .travis.yml 中会用到。

# 指定构建环境是Node.js，当前版本是稳定版
anguage: node_js
node_js: stable

env:
 global:
   - URL_REPO: github.com/Michael728/michael728.github.io.git

# 设置钩子只检测blog-source分支的push变动
branches:
  only:
    - hexo

# 设置缓存文件
cache:
  directories:
    - node_modules

#在构建之前安装hexo环境
before_install:
  - npm install -g hexo-cli

#安装git插件和搜索功能插件
install:
  - npm install

  # 设置git提交名，邮箱；替换真实token到_config.yml文件
before_script:
  - git config user.name "Michael728"
  - git config user.email "649168982@qq.com"
  # 替换同目录下的_config.yml文件中github_token字符串为travis后台刚才配置的变量，注>意此处sed命令用了双引号。单引号无效！
  - sed -i "s/github_token/${GH_TOKEN}/g" _config.yml || exit 1

# 执行清缓存，生成网页操作
script:
  - hexo clean
  - hexo generate
  - echo ${ENV_TEST}
  - hexo deploy

# configure notifications (email, IRC, campfire etc)
# please update this section to your needs!
# https://docs.travis-ci.com/user/notifications/
notifications:
  email:
    - 649168982@qq.com
  on_success: change
  on_failure: always

这份 yml 文件我做了一些调整，hexo deploy 失败，就是会显示失败，而参考文章中有一些写在了 after_scripts 中，不方便查看是否部署成功了。

有[文章](Hexo 自动部署到 Github)介绍了可以对 token 进一步加密，然后在 .travis.yml 中直接配置密码，这样也可以走通，免走了去配置环境变量的步骤。个人还是偏向去配置环境变量.

按照指导，包括官网的指导-Encryption keys，由于网络太慢，没走通；
将密码写在环境中也是比价好的一种方式！

代码库准备

之前的博客代码库只有一个 master 分支，存放的都是 hexo g 命令生成的静态文件。于是，我需要：

本地准备好博客代码库
新建一个叫 hexo 的分支：git checkout -b hexo
添加 .travis.yml 文件
将之前我的博客源文件拷贝到该分之下，并删除node_modules、public文件夹
同时，我也将主题文件下的 .git 目录删除了，因为我并需要 submodule 的方式去下载主题仓库了
然后将站点配置文件进行一下修改

deploy:
- type: git
  #repo: git@github.com:Michael728/michael728.github.io.git
  #下方的gh_token会被.travis.yml中sed命令替换
  repo: https://github_token@github.com/Michael728/michael728.github.io.git

  branch: master
- type: baidu_url_submitter

说明：github_token 这个字段看到了吗？在 .travis.yml 文件中，会使用环境变量 GH_TOKEN 替换掉它的。因为构建机器上没有配置 ssh 免密，所以需要使用这种 token+http 的方式实现代码的推送

到此基本配置完毕，下载新建文章之后，只需要 git push origin hexo 推送到远端分支，在 Travis CI 中会自动执行部署脚本的。

一开始部署都 OK，后来发现博客的分享按钮和图标显示都有问题。后来发现 next 主题下和 next/source/lib/needsharebutton 下都有 .gitignore 文件。这样当然去部署时，不会带相关配置文件了。于是，我将 .gitignore 文件都重命名了。后来再执行推送时，部署就 OK 了。

所以，现在我只需要在 Hexo 分支编辑，就可以自动触发 CI 去发布博客啦。甚至手机端都可以直接写篇博客了！美滋滋~~~

博客访问地址：

https://michael728.github.io/tools/michael728.github.io

总结

整个过程走下来，感觉和我现在工作中打造的 DevOps 流水线系统很像。开源的这些作品有很多优秀的点值得学习和借鉴，需要去多体验。

昨天在家中折腾搭建好的 Gitlab 和 Gitlab-Runner 应该也可以实现这样的功能，因为它也有一个 .gitlab-ci.yml 来定义 CI/CD 流水线。改天有时间，研究一下。

参考

Hexo+github搭建个人博客（三）：Travis CI持续集成,自动部署博客
掘金-Hexo遇上Travis-CI：可能是最通俗易懂的自动发布博客图文教程

Travis CI

Github 项目与 Travis CI 集成

weixin_39618176

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
hexo部署到github上之后无法访问_Github 使用 Travis CI 实现 Hexo 博客自动部署

想学一下 Travis CI 的用法，带着目的学习效果更佳。那么，我最终的目的就是实现 Github 上的Hexo 博客仓库有内容更新后，自动运行 Hexo 部署命更新博客。Travis CITravis CI 在 Github 的 Marketplace 中可以看到，这是它 Marketplace 的链接:Travis CIContinuous Integration，简称 CI：意思是，在一个...
复制链接

扫一扫