[fix]:[FL-56][修复 Buildx 安装阶段构建错误]

Co-authored-by: multica-agent <github@multica.ai>
This commit is contained in:
chengkai3
2026-06-09 00:33:42 +08:00
parent 2a10cc62d8
commit 9d497291e1
3 changed files with 42 additions and 6 deletions
+9 -6
View File
@@ -26,7 +26,7 @@ jobs:
image_tag: ${{ steps.vars.outputs.image_tag }}
steps:
- name: 拉取代码
uses: actions/checkout@v4
uses: actions/checkout@v6
- name: 生成镜像变量
id: vars
@@ -38,17 +38,20 @@ jobs:
echo "image_tag=${GITHUB_SHA}" >> "$GITHUB_OUTPUT"
- name: 安装 Buildx
uses: docker/setup-buildx-action@v3
uses: docker/setup-buildx-action@v4
with:
driver-opts: |
image=docker.m.daocloud.io/moby/buildkit:buildx-stable-1
- name: 登录镜像仓库
uses: docker/login-action@v3
uses: docker/login-action@v4
with:
registry: ${{ env.REGISTRY }}
username: ${{ secrets.REGISTRY_USERNAME }}
password: ${{ secrets.REGISTRY_PASSWORD }}
- name: 构建并推送 API 镜像
uses: docker/build-push-action@v6
uses: docker/build-push-action@v7
with:
context: ./api
file: ./api/Dockerfile
@@ -64,7 +67,7 @@ jobs:
cache-to: type=gha,mode=max,scope=fquiz-api
- name: 构建并推送 Web 镜像
uses: docker/build-push-action@v6
uses: docker/build-push-action@v7
with:
context: ./web
file: ./web/Dockerfile
@@ -104,7 +107,7 @@ jobs:
[ -n "${REGISTRY_PASSWORD}" ] || { echo "::error::缺少 REGISTRY_PASSWORD"; exit 1; }
- name: 拉取代码
uses: actions/checkout@v4
uses: actions/checkout@v6
- name: 准备远端部署目录
uses: appleboy/ssh-action@v1.2.0
+1
View File
@@ -51,6 +51,7 @@
- CORS 来源控制采用“双轨配置”:`API_CORS_ORIGINS`(精确列表)+ `API_CORS_ORIGIN_REGEX`(正则,可选);`API_CORS_ORIGINS` 支持 `*` 和通配符域名并在后端转换为 `allow_origin_regex`
- GitHub Actions 使用 `appleboy/ssh-action` 部署时,慢网环境需显式设置 `command_timeout`(建议 `45m`)并为 `docker compose pull` 增加重试,避免出现 `Run Command Timeout` 直接中断发布。
- 生产发布默认不再依赖 `ghcr.io`:工作流镜像仓库统一通过 `REGISTRY` / `REGISTRY_NAMESPACE` 控制,默认指向阿里云个人版容器仓库 `crpi-u265r07n4blchcqo.cn-shanghai.personal.cr.aliyuncs.com/ck-registry`CI 与远端部署均使用 `REGISTRY_USERNAME` / `REGISTRY_PASSWORD` 登录同一仓库,避免服务器侧访问 GHCR 出现 `Get "https://ghcr.io/v2/": EOF`
- GitHub Actions 若继续使用 `docker/setup-buildx-action` 默认 `docker-container` 驱动,BuildKit builder 会先拉 `moby/buildkit:buildx-stable-1`;在当前网络条件下应显式通过 `driver-opts` 指向镜像站(当前口径:`docker.m.daocloud.io/moby/buildkit:buildx-stable-1`),避免安装 Buildx 阶段因 Docker Hub 超时直接失败。
- `docker compose up -d` 不会重建 `build` 类型服务镜像;开发链路默认使用 `deploy/dev-deploy/compose.yml`,前端代码变更后需执行 `docker compose --env-file deploy/dev-deploy/.env -f deploy/dev-deploy/compose.yml up --build -d web`(必要时先 `docker compose --env-file deploy/dev-deploy/.env -f deploy/dev-deploy/compose.yml build --no-cache web`)。
- `api` 构建若在拉取 `docker.m.daocloud.io/library/python:3.11-slim` 时出现 manifest `EOF`,优先重试 `docker compose --env-file deploy/dev-deploy/.env -f deploy/dev-deploy/compose.yml build api`;若持续失败,可在 `deploy/dev-deploy/.env` 覆盖 `PYTHON_BASE_IMAGE=python:3.11-slim` 走 Docker Hub 兜底。
+32
View File
@@ -0,0 +1,32 @@
## Work Log - 修复 Buildx 安装阶段访问 Docker Hub 超时(2026-06-09
- 背景:
- GitHub Actions run `27150975287``build-and-push` job 的 `安装 Buildx` 步骤失败,后续镜像构建与部署全部被跳过。
- check-run annotation 给出的精确错误为:
- `Head "https://registry-1.docker.io/v2/moby/buildkit/manifests/buildx-stable-1" ... Client.Timeout exceeded while awaiting headers`
- 根因不是仓库镜像构建脚本本身,而是 `docker/setup-buildx-action` 默认 `docker-container` 驱动在启动 BuildKit builder 时,需要先从 Docker Hub 拉 `moby/buildkit:buildx-stable-1`,受外网访问抖动影响直接超时。
- 本次处理:
- `.github/workflows/main.yml`
- `actions/checkout` 升级到 `v6`
- `docker/setup-buildx-action` 升级到 `v4`,并显式指定:
- `driver-opts: image=docker.m.daocloud.io/moby/buildkit:buildx-stable-1`
- 避免 Buildx 初始化再访问 Docker Hub 拉默认 BuildKit 镜像。
- `docker/login-action` 升级到 `v4`
- `docker/build-push-action` 升级到 `v7`
- 兼带收益:
- 消除了该次 run 中出现的 `Node.js 20 actions are deprecated` 预警里的旧版 `checkout/setup-buildx`
- 验证:
- 基线:
- GitHub Actions run `27150975287` 失败,且失败点固定在 `安装 Buildx`
- check-run annotation 可复核到 Docker Hub `moby/buildkit` 拉取超时。
- 修改后:
- `python3` 解析 `.github/workflows/main.yml` 通过。
- `actionlint` 校验变更前/变更后 workflow 均可解析,变更未引入 YAML / Actions 语法问题。
- `git diff --check -- .github/workflows/main.yml` 通过。
- 当前环境限制:
- 无法直接在本地实际执行 GitHub hosted runner 上的 `setup-buildx` 拉起流程,真实恢复效果需要依赖下一次 Actions 运行确认。
- 风险与关注点:
- 本次修复只绕开 BuildKit builder 镜像对 Docker Hub 的依赖;后续若 `Dockerfile` 里的基础镜像或 `docker build --pull` 仍指向不稳定上游,构建阶段仍可能出现其他网络相关失败。