4.4 KiB
title | tags | date | |
---|---|---|---|
博客最近的架构改动 |
|
2024-06-07 23:52:10 |
嗯,是的,我又回来了。最近打算写一篇关于数据驱动UI的博文,于是我又关注起了我的博客,然后发现有个事项好像还没做:更新博客的构建。正好我自己的Git托管服务也搭得差不多了,我就考虑把构建迁移到我自己的服务上。当然,现在这种情况再用GitHub Pages不方便——于是网页就换成Cloudflare Pages托管。
这就是这次架构更新的大概方向。不过,这次改动中我确实遇到了一些问题,这些才是有意思的部分。
Hexo的增量构建
不知道之前有没有人注意博客文章的时间,所有博客文章的更新时间都是一样的,而且实际上没有任何更新(xD)。我一直以为Hexo只能一次构建全部页面,但是这次我想顺便看看有没有增量更新的方案——然后我就发现Hexo其实是支持增量更新的!(GitHub issue)只需要保留db.json
和生成产物文件夹public
就可以了。
所以我在构建的时候,直接将它们缓存起来,这样就可以最小化每次构建的变更(Actions工作流描述文件)。
# ...
- 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 (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。
原来这个是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。