added post: recent changes in my blog arch
All checks were successful
Build & Depoly / Depoly blog (push) Successful in 1m2s
All checks were successful
Build & Depoly / Depoly blog (push) Successful in 1m2s
This commit is contained in:
parent
ef3199f545
commit
931d3706ee
1 changed files with 67 additions and 0 deletions
67
source/_posts/Recent-changes-in-my-blog-arch.md
Normal file
67
source/_posts/Recent-changes-in-my-blog-arch.md
Normal file
|
@ -0,0 +1,67 @@
|
|||
---
|
||||
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。
|
Loading…
Reference in a new issue