使用自动部署之前,我都是用的hexo deploy
把每次生成的public
文件夹上传到github上去,使用自动部署之后,就省略掉了这一步骤,但是多了这三步
git add -A
git commit -m “imformaion”
git push
看似并没有简化自己的操作,实际上好处很多
- 博客源码托管在Github的仓库,避免源码丢失的风险
- Github会记录每一次
commit
,方便回溯 - 高逼格
- ……
关于自动化部署
百度词条中的自动化部署
以及CI\CD
——CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。
github Actions
是 GitHub
的持续集成服务,于2018年10月推出。
还有一个类似的是TravisCI
。
我之前使用的就是TravisCI
,然后出了点小小的问题,其无法使用,然后一直配置不好,我就开始使用GitHub Actions
,而且有大佬说觉得它非常强大,有创意,比 Travis CI 玩法更多。
不多介绍,就推荐几个大佬的文章
不多介绍了,直接说我怎么使用github actions
的,主要chao了大佬的东西。
准备工作
需要一个GitHub
帐号、一个 GitHub Pages
仓库、一个Hexo
博客备份仓库/分支。另外我们还需要获取一个GitHub Personal Access Token
用来推送构建好的文件到我们的GitHub Pages
仓库。具体的操作这里不再重复叙述,有需要了解的可以去看之前的文章。
点开博客备份仓库上方的Settings
,点到左侧的Secrets
项,添加两个秘密环境变量GH_REF
、GH_TOKEN
,值分别填写自己的GitHub Pages
仓库地址(不包含 https:// )和刚刚申请到的GitHub Personal Access Token
。
配置过程
准备工作做好后就可以开始编写GitHub Actions
配置文件了,这里对 Hexo 博客编译部署的步骤进行拆分讲解。
配置文件的目录——在站点目录下新建.github
文件夹,再在其中新建文件夹workflows
,在创建×××××××.yml
文件,命名随意。
触发条件和运行环境
我们设置在master
分支上发生push
操作时触发构建,使用最新的Ubuntu
系统作为编译部署的环境,同时设置一个全局环境变量将时区修改为Asia/Shanghai
(修改原因见 https://xirikm.net/2020/215-1.html),具体的配置内容如下:
1 | name: Blog CI/CD |
建立工作环境
上面的大前提确定后就可以来开始建立我们的工作环境了(注: 后续所有步骤的配置都是接在上面steps
块下的,不要弄混了层级关系)。
首先检出代码,设置一下node
环境,我们这里使用12.x
版本的node.js
:
1 | steps: |
然后设置一下缓存目录以避免每次都要重新下载,从而加快构建速度(官方不建议直接缓存node_modules
目录,所以这里设置的是npm
的下载缓存目录~/.npm
,这样后面仍需要使用npm install
来安装依赖)。这里使用的是package-lock.json
文件的hash
值来标识缓存是否可以命中:
1 | - name: Cache node modules |
最后就是安装依赖了,这个根据自己的需要操作就行,由于我使用了gulp
任务来压缩Hexo
生成的文件,所以我这里除了hexo-cli
还全局安装了gulp
:
1 | - name: Install dependencies |
生成部署文件
这一步简单点hexo g
就行了,我这里多加了一步执行 gulp 任务的操作(将其放在两个step
中而不是一次性执行是为了方便在日志中看到每个操作消耗的时间):
1 | - name: Generate files |
部署博客
我们先将GitHub Pages
仓库克隆过来,将其中的.git
目录移到存放部署文件的public
目录中(为了保留GitHub Pages
仓库的提交历史),然后进入public
目录设置一下提交用户名和邮箱,add
所有文件并提交,最后利用保存在秘密环境变量中的GitHub Personal Access Token
推送到GitHub Pages
仓库中就可以了:
1 | - name: Deploy blog |
完整配置文件
1 | name: Blog CI/CD |
参考
使用 GitHub Actions 自动构建 Hexo 博客
持续更新中
暂时这么样