建议优化 Docker 构建耗时：拆分日常单架构构建和发布多架构构建

[Zker67]

问题

当前 Docker 镜像构建比较重，主要原因是镜像内同时包含 Python/uv、Next 前端构建、Browser Bridge、Chromium 和 Node/npm 运行依赖。如果 CI 默认每次都构建 linux/amd64,linux/arm64，在普通 amd64 GitHub hosted runner 上，linux/arm64 通常会通过 QEMU 模拟执行，系统依赖安装、Chromium 相关依赖处理、镜像导出和 cache 导出都会明显变慢。

这会导致普通提交也承担完整多架构发布成本。对日常开发来说，很多场景只需要快速验证并发布 linux/amd64；多架构镜像更适合放在 tag/release 或手动触发流程中。

建议改动

1. 默认分离日常构建和正式发布构建：

   • main 分支 push 默认只构建 linux/amd64。
   • v* tag 或 release 场景构建 linux/amd64,linux/arm64。
   • workflow_dispatch 增加 platforms 输入，默认 linux/amd64，需要时手动填写 linux/amd64,linux/arm64。

2. cache 策略按场景区分：

   • 单架构日常构建可以使用 cache-to=type=gha,mode=min，减少 cache 导出时间。
   • 多架构发布构建继续使用 cache-to=type=gha,mode=max。

3. 后续可以考虑维护基础 runtime 镜像：

   • 把 Chromium、系统依赖、uv/npm 基础环境前置到基础镜像中。
   • 应用镜像只处理源码、依赖锁定和启动文件。
   • 这是维护成本更高的改法，可以作为后续优化，不必阻塞前两个低风险改动。

参考 workflow 片段

on:
  push:
    branches:
      - main
    tags:
      - v*
  workflow_dispatch:
    inputs:
      platforms:
        description: 构建平台列表
        required: false
        default: linux/amd64

if [[ "${GITHUB_EVENT_NAME}" == "workflow_dispatch" && -n "${REQUESTED_PLATFORMS}" ]]; then
  platforms="${REQUESTED_PLATFORMS}"
elif [[ "${GITHUB_REF_TYPE}" == "tag" ]]; then
  platforms="linux/amd64,linux/arm64"
else
  platforms="linux/amd64"
fi

建议验证

• 对比 linux/amd64 单架构构建和 linux/amd64,linux/arm64 多架构构建的总耗时。
• 确认 main 分支普通提交不会触发 QEMU arm64 构建。
• 确认 tag 或手动指定多架构时仍能发布 multi-platform manifest。
• 镜像启动后检查 /health、Browser Bridge 相关路径和 Grok app-chat 路径。

[github-actions]

AI issue labeler summary (classification based on trusted dev branch evidence): Labels: ci, performance, feature, priority: medium Evidence-sensitive labels considered: performance Confidence: 0.84 Reason: 该 issue 是对 Docker 发布工作流的优化建议，不是明确的功能错误报告。它主要针对 CI 构建策略与耗时表现，提出按场景区分单架构/多架构与缓存模式，属于 CI 侧的性能改进需求。 Code evidence summary: dev 分支证据支持打上 performance 与 ci：.github/workflows/docker-publish.yml 当前 Build and push image 固定 platforms: linux/amd64,linux/arm64 且 cache-to: type=gha,mode=max，确实会在触发时执行较重的多架构构建，和 issue 里的耗时担忧一致。与此同时，dev 也显示该流程目前只在 push tags v* 与 workflow_dispatch 触发，并未在 main 普通 push 上自动运行，因此 issue 中“每次普通提交都承担多架构成本”在 dev 现状下不完全成立。由于 dev 中没有看到按触发场景动态切换 platforms/cache mode 的实现（也未见对应测试或脚本逻辑），不能标记 fixed-in-dev 或 awaiting-release；应作为新的 CI/性能优化特性请求处理。 Bounded dev branch evidence used: - .github/workflows/docker-publish.yml: 仅 tags/workflow_dispatch 触发，无 main push 触发 - docker-publish.yml: buildx 固定 platforms=linux/amd64,linux/arm64 - docker-publish.yml: cache-to 固定 mode=max - Dockerfile: 镜像构建包含 Node 前端构建 + Python + Chromium + npm，构建负担重 - scripts/entrypoint.sh 与 browser_bridge 相关依赖侧面印证镜像运行时组件较多

[github-actions]

AI issue labeler summary (classification based on trusted dev branch evidence): Labels: feature, ci, performance, priority: medium Evidence-sensitive labels considered: performance Confidence: 0.90 Reason: 该 issue 主要是对 CI Docker 发布流程的优化建议（按场景拆分构建平台与缓存策略），属于新增/改进需求而非缺陷报告。 Code evidence summary: dev 分支证据显示当前发布工作流 .github/workflows/docker-publish.yml 只在 v* tag 和 workflow_dispatch 触发，但构建步骤固定为 platforms: linux/amd64,linux/arm64，并始终启用 QEMU（arm64）和 cache-to: type=gha,mode=max。这与 issue 提出的“按日常单架构 vs 发布多架构拆分、并区分 cache 模式”高度相关，且能支持打上 performance（存在可预期的构建耗时优化空间）与 ci（工作流层面改动）标签。另一方面，dev 证据不支持 bug/regression/security：没有显示错误行为或回归，只是流程优化诉求；也不支持 fixed-in-dev/awaiting-release：建议中的 workflow_dispatch platforms 输入、按触发场景动态平台选择、mode=min 策略在 dev 中尚未实现。 Bounded dev branch evidence used: - .github/workflows/docker-publish.yml only triggers on v* tags and workflow_dispatch - Build step hardcodes platforms linux/amd64,linux/arm64 - Workflow always sets up QEMU for arm64 - cache-to is fixed at type=gha,mode=max - Dockerfile includes heavy Chromium/Node/Python build deps, making multi-arch builds costly

[Zker67]

已提交 PR #18：优化 Docker 发布流程，默认单架构构建。

主要处理点：

• 普通 main push 与手动默认构建 linux/amd64。
• tag 发布保留 linux/amd64,linux/arm64 多架构镜像。
• workflow_dispatch 支持通过 platforms 手动指定目标平台。
• 只有目标平台包含 arm 时才启用 QEMU。
• 单架构使用 cache-to=type=gha,mode=min，多架构继续使用 mode=max。

本地验证已通过：git diff --check、YAML 解析、actionlint，以及新增 bash 逻辑的手动、tag、branch 场景模拟。

[zqbxdev]

已确认该问题已在 dev 分支修复并合入。

根本原因简述：原 Docker 发布流程对默认构建场景缺少按触发来源区分的平台选择和缓存策略，导致日常构建容易承担多架构/QEMU 与 cache-to mode=max 的额外成本。现已调整为：普通 main push 与手动默认构建 linux/amd64，v* tag 发布保留 linux/amd64,linux/arm64，workflow_dispatch 可手动指定平台；同时单架构使用 cache-to=type=gha,mode=min，多架构继续使用 mode=max，并仅在目标平台包含 ARM 时启用 QEMU。

解决 Commit：c01f08e55b962feb2f0f2d15c28b9447ad81a594 (ci: optimize docker publish workflow platforms)。

验收记录：已确认本地 dev 与 origin/dev 同步；关键 workflow 片段断言通过；分支/tag/manual 平台选择场景模拟通过；git diff --check 和 workflow LSP diagnostics 通过。全量 unittest 在当前本地环境因缺少/遮蔽依赖无法完整运行，已记录为环境限制，并运行了可用的 test_config.py 子集通过。

感谢 @Zker67 提出的构建耗时优化建议！