从vercel到Github action
内容提要
作者将静态博客从Vercel迁移到使用GitHub Action进行部署，选择了texify3主题并进行了二次开发。通过GitHub Action实现自动化构建和部署，使用R2作为静态文件托管。文章还提到了遇到的问题和解决方法，认为从Vercel升级到GitHub Action更接近正式的CICD流程，是工程师的成长之路。
延伸解读
迁移动因：从Vercel到GitHub Action
作者迁移博客的直接原因是Vercel部署时出现Sass兼容性问题，导致CSS无法编译，博客无法正常使用。同时，作者认为GitHub Action更接近正式的CICD流程，能借此学习新技能。这反映了在工具选型时，除了功能，稳定性和学习价值也是重要考量。
技术选型：Hugo、GitHub Action与Cloudflare R2
作者选用Hugo生成静态文件，GitHub Action实现自动化构建和部署，Cloudflare R2托管静态文件。由于GitHub Pages仅支持公共仓库，而作者希望保护博客源文件，因此选择R2作为私有存储方案。这种组合兼顾了自动化与隐私需求。
部署流程与版本控制
GitHub Action流水线分为Build和Deploy两个Job。Build阶段安装Hugo和Node.js依赖，生成ShortID作为版本前缀，并编译Hugo站点；Deploy阶段将构建产物上传至R2的ShortID目录，实现版本隔离。ShortID通过临时文件在Job间传递，确保部署路径一致。
遇到的问题与解决方式
迁移中遇到两个主要问题：R2不支持自动尝试index.html，导致目录访问404；以及文件版本管理。作者通过生成ShortID目录实现版本控制，并创建根目录index.html自动跳转到最新版本。此外，在Cloudflare添加重定向规则，为非资源路径追加index.html，解决了404问题。
Q&A
为什么作者选择将博客从Vercel迁移到GitHub Action？
作者迁移的原因是Vercel在部署时存在Sass兼容性问题，导致CSS无法编译。
在迁移过程中，作者使用了哪些技术栈？
作者使用了Hugo、GitHub Action和Cloudflare R2作为静态文件托管。
GitHub Action的自动化构建和部署是如何实现的？
通过编写yaml文件，分为Build和Deploy两个部分，Build部分安装依赖并生成ShortID，Deploy部分上传构建的文件到R2。
作者在迁移过程中遇到了哪些问题？
作者遇到了R2的文件版本问题和访问404的问题。
如何解决R2的404访问问题？
通过在Cloudflare中添加重定向规则，强制在非资源链接后面添加index.html。
从Vercel迁移到GitHub Action对作者的成长有什么影响？
作者认为这一过程更贴近正式的CICD流程，体现了工程师的成长。
