68 lines
4.4 KiB
Markdown
68 lines
4.4 KiB
Markdown
|
---
|
|||
|
|
title: 博客最近的架构改动
|
|||
|
|
tags:
|
|||
|
|
- 博客功能更新
|
|||
|
|
date: 2024-06-07 23:52:10
|
|||
|
|
---
|
|||
|
|
|
|||
|
|
|
|||
|
|
嗯，是的，我又回来了。最近打算写一篇关于数据驱动UI的博文，于是我又关注起了我的博客，然后发现有个事项好像还没做：更新博客的构建。正好我自己的Git托管服务也搭得差不多了，我就考虑把构建迁移到我自己的服务上。当然，现在这种情况再用GitHub Pages不方便——于是网页就换成Cloudflare Pages托管。
|
|||
|
|
|
|||
|
|
这就是这次架构更新的大概方向。不过，这次改动中我确实遇到了一些问题，这些才是有意思的部分。
|
|||
|
|
|
|||
|
|
<!--more-->
|
|||
|
|
|
|||
|
|
## Hexo的增量构建
|
|||
|
|
|
|||
|
|
不知道之前有没有人注意博客文章的时间，所有博客文章的更新时间都是一样的，而且实际上没有任何更新（xD）。我一直以为Hexo只能一次构建全部页面，但是这次我想顺便看看有没有增量更新的方案——然后我就发现Hexo其实是支持增量更新的！（[GitHub issue](https://github.com/hexojs/hexo/issues/2920)）只需要保留`db.json`和生成产物文件夹`public`就可以了。
|
|||
|
|
|
|||
|
|
所以我在构建的时候，直接将它们缓存起来，这样就可以最小化每次构建的变更（[Actions工作流描述文件](https://code.lightstands.xyz/Rubicon/blog/src/commit/4bdac4215e3562a9d41ea9307df6a986fab4084f/.forgejo/workflows/depoly.yml)）。
|
|||
|
|
|
|||
|
|
````yaml
|
|||
|
|
# ...
|
|||
|
|
- name: Cache Generated Files
|
|||
|
|
id: files-cache
|
|||
|
|
uses: actions/cache@v4
|
|||
|
|
with:
|
|||
|
|
path: |
|
|||
|
|
public/**
|
|||
|
|
db.json
|
|||
|
|
key: generated-files-1
|
|||
|
|
# ...
|
|||
|
|
````
|
|||
|
|
|
|||
|
|
当需要重新构建整个网站的时候，只需要改一下key就可以了。我想到这回事是因为另一个惨痛教训……
|
|||
|
|
|
|||
|
|
## actions/checkout@v4无法检出LFS文件
|
|||
|
|
这次迁移还涉及到另一个我想试用的新东西：[Git LFS](https://git-lfs.com) (Large File System)。作为一个博客，有点二进制大文件再正常不过了：图片、pdf、幻灯片……所以我按照说明在本地安装了程序、设定参数、Commit、推送、等待部署。看起来一切都挺好，然后我就睡觉去了。
|
|||
|
|
|
|||
|
|
第二天起床打开某篇文章一看：我的图片呢？打开开发者工具查看一下网络请求，是有这个文件，但是好像不是图片，而且统一在130字节左右。我知道检出LFS需要一个额外的下载过程，所以我检查了一下actions/checkout@v4，发现它有一个默认不启用的`lfs`参数。
|
|||
|
|
|
|||
|
|
看来就是这个问题，我就打开了这个功能，等待图片回到我的网站。
|
|||
|
|
|
|||
|
|
````
|
|||
|
|
[command]/usr/bin/git lfs fetch origin refs/remotes/origin/master
|
|||
|
|
fetch: Fetching reference refs/remotes/origin/master
|
|||
|
|
...
|
|||
|
|
error: failed to fetch some objects from 'https://code.lightstands.xyz/Rubicon/blog.git/info/lfs'
|
|||
|
|
::remove-matcher owner=checkout-git::
|
|||
|
|
::error::The process '/usr/bin/git' failed with exit code 2
|
|||
|
|
````
|
|||
|
|
|
|||
|
|
“？”
|
|||
|
|
|
|||
|
|
是不是遇上了和Forgejo Actions一样的网络问题（DNS不生效导致我没办法隔离执行actions的网络）？我怀疑是因为我手动将代码托管网站指定为内网地址造成的，于是我登上服务器修改了hosts，问题依旧。
|
|||
|
|
|
|||
|
|
然后我就只能在网络上漫游，寻找一个答案。然后，啊哈，我发现你啦！就是这个：[#164 'actions/checkout@v3' with LFS fails because of double auth header on gitea.com/gitea/act_runner](https://gitea.com/gitea/act_runner/issues/164#issuecomment-739631)。
|
|||
|
|
|
|||
|
|
原来这个是actions/checkout的bug，它会为两个相同的域名设置相同的HTTP头用作验证，导致HTTP头重复了。如果HTTP服务器比较严格的话就会拒绝服务。因为我没在Nginx的日志里找到相关信息，只能死马当活马医，先试试他的workaround，结果就能用了。
|
|||
|
|
|
|||
|
|
但是增量更新没有更新老文件，于是我再重新生成整个网站，图片这下就出现了。
|
|||
|
|
|
|||
|
|
大概是LFS用的人真的不多吧。
|
|||
|
|
|
|||
|
|
## Robots.txt
|
|||
|
|
这个是我偶然发现的。我想用Google的PageInsight看一下我网页的加载速度，自我得瑟一下（xD）。然后发现在SEO这项下面提示Robots.txt格式错误，里面是我的主页。
|
|||
|
|
|
|||
|
|
这大概是因为Cloudflare Pages对所有文件名找不到的请求返回主页（嗯，`index.html`，有人把这个叫做“伪静态”），所以如果没有Robots.txt，它也会返回主页。这也是个GitHub Pages没有的功能，所以我也没注意。为了正常被索引，我只好自己添加了一个空的Robots.txt。
|