如何搭建个人网页(七)—— Gitlab Pages部署(二)
开始
在第二章中,我们讲了如何将 Hexo 生成的网页部署到 GitLab Pages,但有一个比较麻烦的地方:每次改写网页或新增 Markdown 文件后,运行 hexo deploy
部署时,都需要重新在 GitLab 项目中上传 .gitlab-ci.yml
文件以触发流水线。这无疑非常麻烦。
经过两小时的研究,我发现问题的根源在于:通过 hexo deploy
部署网站实际上是 GitHub Pages 的惯用方式,而 Hexo 官方文档中对于 GitLab Pages 的部署建议则是另一种方法。
本章将讨论部署到 GitHub Pages 和 GitLab Pages 的区别,以及当我们错误地使用 GitHub Pages 的方式部署到 GitLab Pages 时(是的,这种“粗心”就是我了),有没有快捷的补救办法来避免每次上传 .gitlab-ci.yml
文件。
说明:这里所说的部署是指改写网页或新增 Markdown 文件后,重新部署更新网站,而非从零开始的部署流程。
部署到 GitHub Pages 的流程
第二章中所讲的办法,其实是标准的 GitHub Pages 部署流程。操作步骤如下:
在博客目录中进行修改,比如更改配置或新增 Markdown 文件;
依次运行熟悉的 Hexo 命令三件套:
1
2
3hexo clean # 这一步是,清空public/目录
hexo generate # 这一步是,在public/目录中生成静态网页
hexo deploy # 这一步是,将public/目录推送到远程仓库
完成以上操作后,如果目标是 GitHub Pages,网站即可自动更新。
但对于 GitLab Pages,我们还缺少 .gitlab-ci.yml
文件来触发流水线,因此每次都需手动上传该文件,这显然不是 Hexo 官方推荐的 GitLab Pages 部署方式。
部署到Gitlab Pages流程
将 Hexo 部署到 GitLab Pages | Hexo
2023年最新详细教程!手把手教你搭建Hexo + GitLab个人博客_如何搭建 hexo gitlab-CSDN博客
查看 Hexo 官方文档后,我了解到正确的 GitLab Pages 部署方法应如下:
在 GitHub 仓库中,通常只存储静态网页代码(即
public/
目录的内容);而在 GitLab 仓库中,需存储完整的源代码(即blog/
目录的内容)。此时,GitLab 项目的目录结构应类似于:1
2
3
4
5├── _config.yml
├── package.json
├── source/
├── themes/
└── .gitignore在
.gitignore
文件中,确保包含以下行:1
public/
启用 GitLab 的共享运行器:
依次进入 Settings > CI/CD > Runners > Enable shared runners for this project。在项目根目录(即
blog/
)中添加.gitlab-ci.yml
文件(只需添加一次),内容如下(将node:16
中的16
替换为你的 Node 主版本号):1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17image: node:16-alpine
cache:
paths:
- node_modules/
before_script:
- npm install hexo-cli -g
- npm install
pages:
script:
- npm run build
artifacts:
paths:
- public
rules:
- if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH提交代码并推送:
1
2
3git add .
git commit -m "Add CI/CD pipeline"
git push
GitLab 的 CI/CD 管道会自动运行,部署成功后即可访问网站。此后,只需更新 Markdown 文件或配置并将更改推送到仓库,流水线会自动运行,无需再手动上传 .gitlab-ci.yml
文件。
如何补救——一个取巧办法
由于看了一份错误的教程,导致我用了部署到Github Pages的流程(即hexo命令三件套)来部署到了Gitlab Pages,因此我想有没有一个补救办法,在还是用hexo命令三件套的前提下,不用每次跑到gitlab项目中重新上传.gitlab-ci.yml文件?
很简单,在运行 hexo clean
和 hexo generate
后,将 .gitlab-ci.yml
文件复制到 public/
目录,再运行 hexo deploy
,即可触发流水线。这种方式虽然“取巧”,但有效解决了问题。
为了方便,我写了一个powershell脚本 deploy.ps1 来执行这个过程:
1 | # Step 1: Clean Hexo files |
这个脚本的核心其实就是执行了四个命令,即:
1 | hexo clean |
由于Windows PowerShell的默认执行策略受到限制,因此我们可能无法运行脚本。所以我们使用以下命令将执行策略设置为Unrestricted
以执行脚本。
1 | Set-ExecutionPolicy Unrestricted |
此外,由于.gitlab-ci.yml文件是隐藏文件,还需要到站点配置文件_config.yml中,将ignore_hidden设置为false(默认为true)。
1 | deploy: |
完成配置后,只需运行脚本 .\deploy.ps1
即可更新网站,简单高效!
总结
通过以上方法,无论是正确的 GitLab Pages 部署方式,还是取巧的补救方法,都能实现自动触发流水线,让 Hexo 部署到 GitLab Pages 的体验更加顺畅。