前言
Note26/4/25更新:Workflow 增加 submodules 拉取避免缺少变量。
Innei 疯狂使用 Claude 等 AI 工具把 Shiroi 重写了一遍设计风格,改名成了 Yohaku。但是吧,refactor 步子太大一堆破坏性变更,整得原来使用 GitHub Actions 构建的镜像已经没法在部署镜像后正常使用了。在使用“帮帮我,Copilot”大法排查出问题并进行修复之后,整理了一下问题,结合原有的资料,写一版 2026 年用 Actions 构建一个能跑的 Yohaku Docker 镜像的教程。
变了什么?
太长不看的结论:原先只需要在运行时加的环境变量,现在在构建时也需要传入,否则编译后的产物用原有方式进行部署,访问时会炸 Invalid base URL: /api/v2/auth。
究其原因,在于构建镜像时没有注入 BASE_URL 等参数,导致构建编译阶段默认把 NEXT_PUBLIC_API_URL 编译成了 /api/v2。当容器启动并进行服务端渲染时,由于它读取的是打包好的编译产物,NEXT_PUBLIC_API_URL 还是写死的 /api/v2,所以出现了报错。所以需要在构建阶段就得把 BASE_URL 这个参数设置好。
思路
和 PaloMiku 之前写的教程类似但有不同:使用 GitHub Actions 定期从上游私有仓库拉取更新,并使用变基操作加上自己的变更,再使用另一个工作流完成添加变量并构建 Docker 镜像,以及发布到 GitHub Packages 的流程。
其中前半段的工作流可以参考我写的教程:破事水 | Actions 同步上游项目及合并到自己分支
后面构建镜像部分的 Workflow 参考如下(用了一堆轮子),在 .github/workflows 目录下新建 yml 工作流,将以下内容粘贴提交:
这样就可以实现简单的构建并上传 Github Registry 镜像。此外,至少需要在仓库 Settings → Secrets and variables → Actions 中的 Repository secrets 配置 BASE_URL 变量,变量的值是部署的 Core 后端所绑定的域名(如 https://api.example.com),除此之外其他变量按需添加。完成后跑一遍工作流即可构建镜像。
Note至于为什么不配置
NEXT_PUBLIC_API_URL和NEXT_PUBLIC_GATEWAY_URL这两个经典变量,主要仓库自带的Dockerfile文件里边已经注明了这两个变量的值是基于BASE_URL的,所以可以不用添加。当然有问题了也可以在 Workflow 和 Secret 里边添加对应的变量。
使用
编译完成后可以在自己项目页面右侧的 Packages 找到自己构建的镜像。
在服务器上拉取镜像前,需要先配置 Docker 私有仓库。输入以下指令登录 Github Registry 私有仓库:
输入账号和有访问权限的 Github Access Token,确认登录后即可拉取私有仓库镜像。如果你用的是 1Panel,也可以在容器-仓库中直接添加配置私有仓库。
配置完成后可以使用如下 Docker Compose 文件直接部署镜像:
其中 images 填写你看到的镜像信息(一般来说会直接以仓库名命名镜像,类似于 ghcr.io/username/repo_name:latest)
收尾
自此,使用 Actions 构建镜像并直接部署的教程也算是结束了,关键点还是在于在构建镜像的过程中引入变量,别的步骤差不了多少。有问题可评论区提问咨询或者使用 AI 和搜索引擎进行理解。
参考内容和相关链接如下:
- PaloMiku 的 GitHub Action 构建 Shiroi Docker 镜像
- innei-dev/shiroi-deploy-action (Innei 自动化部署 Yohaku 的轮子,Readme 也是告诉说需要在构建时传递变量了)
- 破事水 | Actions 同步上游项目及合并到自己分支