v0.8.2 —— 容器镜像发布链路修复（补发 v0.8.0 / v0.8.1 缺失的镜像）

桌面产物与 v0.8.0 相同（桌面版本线独立，当前 0.6.0，本版未改动桌面代码）。

本版唯一的实质改动

web/Dockerfile 的基础镜像源改为 ARG NODE_IMAGE 可覆盖，默认回 Docker Hub 官方
node:22-alpine。这是让容器镜像真正能发出去的那一刀。

为什么连续两个版本都没有镜像

版本	Build	Publish image (GHCR)	原因
v0.8.0	skipped	skipped	Security Audit 判红（vite 三连公告）→ 连锁 skip
v0.8.1	success	failure	门禁已绿，但 Docker 构建失败于基础镜像源
v0.8.2	success	success	修掉基础镜像源

v0.8.1 的 CI 实测是本次定位的依据：Build success 而 Publish image failure，
错误固定为——

#5 ERROR: failed to do request: Head "https://docker.m.daocloud.io/v2/library/node/manifests/22-alpine"
  dial tcp: lookup docker.m.daocloud.io on 168.63.129.16:53: no such host

web/Dockerfile 三个 FROM 此前写死第三方镜像源 docker.m.daocloud.io，该源自
2026-10-20 21:41 UTC 最后一次成功拉取后失效。此后 main 上每一次 push 的
Publish image (GHCR) 全部 failure——也就是说，不只是没发版，是连 main 的镜像都断了。

实测双侧网络，结论正好相反：

环境	docker.m.daocloud.io	Docker Hub
本机（国内网络）	可达（HTTP 401）	不可达（curl 000）
GitHub 托管 runner	NXDOMAIN	可达

把只在一侧可用的第三方镜像源写死进 Dockerfile，等于把发布链路押在别人的可用性上。
v0.7.2 之所以有镜像，只是因为那个源当时还活着。

修复形态

ARG NODE_IMAGE=node:22-alpine
FROM ${NODE_IMAGE} AS deps
FROM ${NODE_IMAGE} AS builder
FROM ${NODE_IMAGE} AS runner

• 默认回 Docker Hub 官方镜像，CI/生产开箱可用
• 国内/内网换源改为构建时覆盖，不改默认值（改默认值就等于把 CI 又押给第三方）：
  docker build --build-arg NODE_IMAGE=docker.m.daocloud.io/library/node:22-alpine .
• 顺带把「三阶段必须同 node 版本同镜像源」从靠人记住变成结构保证：镜像源收敛成
  单个 ARG，改一处即全改，版本错配不可能再发生

使用

docker pull ghcr.io/levango7/corps:0.8.2
# 国内/内网如需换源构建：
docker build --build-arg NODE_IMAGE=docker.m.daocloud.io/library/node:22-alpine ./web

升级说明

• 数据库迁移：无。本版相对 v0.8.0/v0.8.1 零业务代码变更，无需备份数据。
• 需要跑迁移的是 v0.7.2 → v0.8.0 那一跳（4 条迁移，其中
  20261007000000_dedup_task_conversations 会删数据）。若还没升到 v0.8.0，
  请先按 v0.8.0 release 的说明操作：
  pg_dump -t conversations -t messages -t conversation_members -t chat_presences > backup.sql
  并以 BYPASSRLS 角色执行迁移。

已知缺口（建议单独修）

CI 完全不验证 Dockerfile：PR 事件下 Publish image (GHCR) 是 skipped，
Build job 只跑 pnpm run build。本次缺陷能一路潜伏到发布阶段才暴露，根子就在这里。
已记入 CHANGELOG，建议补一条 Docker 构建冒烟检查。