fix: Worker构建fallback改用buildx，修复DooD模式下基础镜像构建失败 #702

Merged

xiaoxia merged 4 commits from fix/worker-build-dood-fallback into develop 2026-07-22 11:39:34 +08:00

Conversation 5 Commits 4 Files Changed 3

+35 -5

xiaoxia commented 2026-07-22 10:47:41 +08:00

Owner

Copy Link

Copy Source

背景

Worker构建在基础镜像缓存miss时，fallback到本地构建使用普通docker build，在DooD（Docker out of Docker）模式下失败。

根因：DooD模式下，docker daemon运行在宿主机上，checkout的代码在runner容器内。普通docker build -f infra/docker/xxx.Dockerfile . 会从宿主机当前目录找Dockerfile，找不到。

主构建为什么能成功：主构建设计上使用docker buildx build --driver docker-container，buildx会把context（源代码）传输到builder容器中，因此在DooD下能正常工作。

修复方案

在pre-build fallback路径中，也使用buildx docker-container驱动来构建基础镜像，和主构建保持一致。

改动

• ci-pipeline.yml：Pre-build worker base images步骤的fallback构建
  • 初始化buildx builder（docker-container驱动，复用主构建的builder名）
  • docker build → docker buildx build --load

影响

• 修复新runner首次构建、缓存失效、依赖更新后的Worker构建失败问题
• 正常有缓存的情况不受影响（不会走到fallback路径）
• 不改变构建产物
• 复用主构建的builder，不额外占用资源

## 背景 Worker构建在基础镜像缓存miss时，fallback到本地构建使用普通docker build，在DooD（Docker out of Docker）模式下失败。 **根因**：DooD模式下，docker daemon运行在宿主机上，checkout的代码在runner容器内。普通docker build -f infra/docker/xxx.Dockerfile . 会从宿主机当前目录找Dockerfile，找不到。 **主构建为什么能成功**：主构建设计上使用docker buildx build --driver docker-container，buildx会把context（源代码）传输到builder容器中，因此在DooD下能正常工作。 ## 修复方案 在pre-build fallback路径中，也使用buildx docker-container驱动来构建基础镜像，和主构建保持一致。 ### 改动 - ci-pipeline.yml：Pre-build worker base images步骤的fallback构建 - 初始化buildx builder（docker-container驱动，复用主构建的builder名） - docker build → docker buildx build --load ## 影响 - 修复新runner首次构建、缓存失效、依赖更新后的Worker构建失败问题 - 正常有缓存的情况不受影响（不会走到fallback路径） - 不改变构建产物 - 复用主构建的builder，不额外占用资源

xiaoxia added 1 commit 2026-07-22 10:47:41 +08:00

fix: Worker构建fallback改用buildx，修复DooD模式下基础镜像构建失败 a39680dbca

gitea-actions bot commented 2026-07-22 10:49:23 +08:00

Copy Link

Copy Source

🚀 预览环境已部署

项目	详情
PR号	#702
预览链接	https://pr-702.preview.xiaoxiajianji.com
API环境	staging

💡 预览环境使用 staging API 数据，请勿在预览环境中操作重要数据。

🔄 每次提交新代码后预览环境会自动更新。

🗑️ PR 关闭或合并后，预览环境会自动清理。

🚀 **预览环境已部署** | 项目 | 详情 | |------|------| | PR号 | #702 | | 预览链接 | [https://pr-702.preview.xiaoxiajianji.com](https://pr-702.preview.xiaoxiajianji.com) | | API环境 | staging | > 💡 预览环境使用 staging API 数据，请勿在预览环境中操作重要数据。 > > 🔄 每次提交新代码后预览环境会自动更新。 > > 🗑️ PR 关闭或合并后，预览环境会自动清理。

xiaoxia added 1 commit 2026-07-22 10:50:38 +08:00

chore: trigger CI for worker dood fallback fix 61f0601cd4

xiaoxia added 1 commit 2026-07-22 11:01:13 +08:00

fix: pre-build fallback构建增加3次重试，应对buildx容器偶发不稳定 7a1f7c89b5

auto-approve-bot approved these changes 2026-07-22 11:06:00 +08:00

auto-approve-bot left a comment

Collaborator

Copy Link

Copy Source

CI全绿，自动审批通过。

CI全绿，自动审批通过。

auto-approve-bot approved these changes 2026-07-22 11:06:00 +08:00

auto-approve-bot left a comment

Collaborator

Copy Link

Copy Source

CI全绿，自动审批通过。

CI全绿，自动审批通过。

xiaoxia added 1 commit 2026-07-22 11:20:30 +08:00

fix: worker基础镜像改用阿里云ACR，提升pull速度 ed061aae3e

auto-approve-bot commented 2026-07-22 11:26:54 +08:00

Collaborator

Copy Link

Copy Source

📊 审查概览

• 整体评价：需修改
• 严重问题数量：2 个
• 一般建议数量：1 个

❌ 需修改的问题（严重）

1. [.gitea/workflows/ci-pipeline.yml: ~650-670] 构建失败未正确退出

   • 问题描述：在 for attempt in 1 2 3 的重试循环中，如果 docker buildx build 连续 3 次均失败，循环结束后脚本会继续向下执行，而不是报错终止 CI 流程。这会导致后续步骤（如 echo "fallback=true"）正常执行，掩盖了构建失败的事实，可能导致 CI 误判为成功。
   • 修改建议：在循环结束后增加状态检查。如果最后一次构建仍然失败，应显式执行 exit 1 或其他错误处理逻辑。例如：

     # ... 循环结束
     if [ $attempt -eq 3 ]; then
       echo "构建最终失败"
       exit 1
     fi
     

2. [infra/docker/worker.Dockerfile: 14, 36] 基础镜像来源与 CI 逻辑不一致

   • 问题描述：ci-pipeline.yml 中花费资源构建了本地的 worker-base-builder 和 worker-base-runtime 镜像（使用 --load 加载到本地）。然而，worker.Dockerfile 中的 FROM 指令被硬编码为从阿里云拉取镜像（xiaoxia-registry...）。这导致 CI 中构建的本地镜像被 worker.Dockerfile 忽略，不仅浪费了 CI 构建时间，还可能导致运行时使用的镜像版本与 CI 刚构建的代码不一致。
   • 修改建议：
     1. 如果意图是使用本地构建的产物，应在 Dockerfile 中使用 ARG 动态传入基础镜像名，或者保持使用本地构建时的镜像命名；
     2. 如果意图是直接使用云上镜像，应删除 ci-pipeline.yml 中对应的本地构建步骤以节省资源。

💡 改进建议（一般）

1. [infra/docker/worker.Dockerfile: 14, 36] 避免使用 :latest 标签
   • 具体内容：基础镜像使用了 :latest 标签。虽然这是从旧代码继承过来的习惯，但在生产环境或 CI 环境中，latest 标签具有不确定性，可能导致构建不可复现。建议使用具体的版本号或 Commit Hash 作为镜像标签，确保构建的一致性。

✅ 良好实践

• 在 CI 脚本中引入了 docker buildx 的 docker-container 驱动，解决了 DooD (Docker-outside-of-Docker) 模式下的可见性问题。
• 针对偶发的网络或构建不稳定问题，引入了重试机制（虽然需补充失败处理），这是一种提升 CI 稳定性的良好实践。

---

_{🤖 由 AI 代码审查机器人自动生成 | 2026-07-22 11:26:54 | 模型:}

### 📊 审查概览 - **整体评价**：需修改 - **严重问题数量**：2 个 - **一般建议数量**：1 个 ### ❌ 需修改的问题（严重） 1. **[.gitea/workflows/ci-pipeline.yml: ~650-670] 构建失败未正确退出** - **问题描述**：在 `for attempt in 1 2 3` 的重试循环中，如果 `docker buildx build` 连续 3 次均失败，循环结束后脚本会继续向下执行，而不是报错终止 CI 流程。这会导致后续步骤（如 `echo "fallback=true"`）正常执行，掩盖了构建失败的事实，可能导致 CI 误判为成功。 - **修改建议**：在循环结束后增加状态检查。如果最后一次构建仍然失败，应显式执行 `exit 1` 或其他错误处理逻辑。例如： ```bash # ... 循环结束 if [ $attempt -eq 3 ]; then echo "构建最终失败" exit 1 fi ``` 2. **[infra/docker/worker.Dockerfile: 14, 36] 基础镜像来源与 CI 逻辑不一致** - **问题描述**：`ci-pipeline.yml` 中花费资源构建了本地的 `worker-base-builder` 和 `worker-base-runtime` 镜像（使用 `--load` 加载到本地）。然而，`worker.Dockerfile` 中的 `FROM` 指令被硬编码为从阿里云拉取镜像（`xiaoxia-registry...`）。这导致 CI 中构建的本地镜像被 `worker.Dockerfile` 忽略，不仅浪费了 CI 构建时间，还可能导致运行时使用的镜像版本与 CI 刚构建的代码不一致。 - **修改建议**： 1. 如果意图是使用本地构建的产物，应在 Dockerfile 中使用 `ARG` 动态传入基础镜像名，或者保持使用本地构建时的镜像命名； 2. 如果意图是直接使用云上镜像，应删除 `ci-pipeline.yml` 中对应的本地构建步骤以节省资源。 ### 💡 改进建议（一般） 1. **[infra/docker/worker.Dockerfile: 14, 36] 避免使用 :latest 标签** - **具体内容**：基础镜像使用了 `:latest` 标签。虽然这是从旧代码继承过来的习惯，但在生产环境或 CI 环境中，`latest` 标签具有不确定性，可能导致构建不可复现。建议使用具体的版本号或 Commit Hash 作为镜像标签，确保构建的一致性。 ### ✅ 良好实践 - 在 CI 脚本中引入了 `docker buildx` 的 `docker-container` 驱动，解决了 DooD (Docker-outside-of-Docker) 模式下的可见性问题。 - 针对偶发的网络或构建不稳定问题，引入了重试机制（虽然需补充失败处理），这是一种提升 CI 稳定性的良好实践。 --- _{🤖 由 AI 代码审查机器人自动生成 | 2026-07-22 11:26:54 | 模型:} <!-- AI_CODE_REVIEW_AUTO_COMMENT -->

xiaoxia merged commit 35f92f8101 into develop 2026-07-22 11:39:34 +08:00

gitea-actions bot commented 2026-07-22 11:39:52 +08:00

Copy Link

Copy Source

🗑️ 预览环境已清理

PR #702 已关闭或合并，对应的预览环境已被清理。

如有需要，可以重新打开 PR 来重新生成预览环境。

🗑️ **预览环境已清理** PR #702 已关闭或合并，对应的预览环境已被清理。 > 如有需要，可以重新打开 PR 来重新生成预览环境。

Sign in to join this conversation.

Reviewers

No Reviewers

auto-approve-bot

Labels

Clear labels

P0

阻塞性，必须立即处理

P1

高优先级

P2

中优先级

P3

低优先级/后考虑

architecture

架构设计

backend

后端相关

blocked

阻塞中

bug

Bug修复

ci-bug

CI本身的bug

ci-optimization

CI优化类任务

ci-pipeline

CI流水线/workflow相关

cleanup

代码清理

devops

运维/部署/CI

documentation

文档相关

feature

新功能

frontend

前端相关

question

需要讨论确认

ready

PR CI通过，可合并

refactor

代码重构

No Label

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

auto-approve-bot xiaoxia

No Assignees

3 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: xiaoxia/xiaoxia-saas#702