chore(ci): optimize docker publish workflow
This commit is contained in:
yinjianm
+129
@@ -0,0 +1,129 @@
|
||||
# 变更提案: optimize-docker-publish-workflow
|
||||
|
||||
## 元信息
|
||||
```yaml
|
||||
类型: 优化
|
||||
方案类型: implementation
|
||||
优先级: P1
|
||||
状态: 已确认
|
||||
创建: 2026-04-18
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 1. 需求
|
||||
|
||||
### 背景
|
||||
当前 `.github/workflows/docker-publish.yml` 在每次 push 到 `master` / `new-dev` 时都会执行双架构镜像构建并推送。
|
||||
现有流程存在几个明显的性能与正确性问题：
|
||||
|
||||
- Dockerfile 在构建过程中重新 `git clone` 仓库和子模块，绕过了 Actions 已 checkout 的工作区。
|
||||
- workflow 通过 `CACHEBUST=${{ github.sha }}` 强制让源码层每次失去缓存，以确保 `git clone` 拉到新代码，但这也让缓存收益极低。
|
||||
- workflow 中“Get version”在“Extract metadata”之后，`steps.get_version.outputs.version` 的引用顺序不正确。
|
||||
- `build-push-action` 同时声明了 `push: true` 和 `outputs: type=registry,push=true`，存在冗余。
|
||||
- QEMU 配置包含 `amd64`，但原生 `ubuntu-latest` 已能直接构建 `amd64`。
|
||||
|
||||
### 目标
|
||||
- 在不改变现有分支触发与双架构产物策略的前提下，缩短 Docker 发布耗时。
|
||||
- 保持 `master` / `new-dev` 的镜像输出逻辑不变。
|
||||
- 修正 workflow 中的明显顺序与冗余配置问题。
|
||||
|
||||
### 约束条件
|
||||
```yaml
|
||||
时间约束: 当前回合内完成方案、实现和基本验证
|
||||
性能约束: 优先优化热路径，不引入新的外部依赖
|
||||
兼容性约束: 保持 master/new-dev 双架构发布行为不变
|
||||
业务约束: 不通过减少镜像产物种类来换速度
|
||||
```
|
||||
|
||||
### 验收标准
|
||||
- [ ] `docker-publish.yml` 保持 `master` / `new-dev` 触发和双架构推送
|
||||
- [ ] Dockerfile 改为使用 GitHub Actions 工作区源码，而不是在构建阶段重新 `git clone`
|
||||
- [ ] workflow 去除明显冗余和错误顺序配置
|
||||
- [ ] `.dockerignore` 收紧不必要上下文，减少上传到 BuildKit 的内容
|
||||
|
||||
---
|
||||
|
||||
## 2. 方案
|
||||
|
||||
### 技术方案
|
||||
采用“保留产物策略不变、优化构建输入与缓存路径”的方案：
|
||||
|
||||
1. `actions/checkout` 增加 `submodules: recursive`，让 CI 工作区直接具备完整源码与子模块。
|
||||
2. 修改 Dockerfile，删除构建期 `git clone` / `git submodule update` 逻辑，改为直接 `COPY` 工作区源码。
|
||||
3. 删除 workflow 中为配合构建期 `git clone` 而存在的 `CACHEBUST` build arg。
|
||||
4. 修正 metadata/version 步骤顺序，移除无效的“Update version in app.php”和冗余 `outputs` 配置。
|
||||
5. 收紧 `.dockerignore`，排除 `.git`、`.github`、`.helloagents` 等不会进入运行时镜像的目录。
|
||||
6. 保留双架构构建，但只在 QEMU 中声明需要模拟的 `arm64`。
|
||||
|
||||
### 影响范围
|
||||
```yaml
|
||||
涉及模块:
|
||||
- .github/workflows/docker-publish.yml: 发布编排与构建参数
|
||||
- Dockerfile: 镜像构建输入与缓存路径
|
||||
- .dockerignore: 构建上下文裁剪
|
||||
预计变更文件: 3
|
||||
```
|
||||
|
||||
### 风险评估
|
||||
| 风险 | 等级 | 应对 |
|
||||
|------|------|------|
|
||||
| 直接使用工作区源码后，若 checkout 未带子模块，构建会缺少 admin dist | 中 | 在 checkout 中显式启用 `submodules: recursive` |
|
||||
| `.dockerignore` 排除过多文件导致运行时缺资源 | 中 | 只排除明显不应进入镜像的 Git/CI/本地知识库目录 |
|
||||
| 删除构建期 `git clone` 后，版本号注入逻辑与现有预期不一致 | 低 | 移除当前本就不会进镜像的版本更新步骤，避免继续保留伪生效逻辑 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 技术设计（可选）
|
||||
|
||||
> 本次为 CI 与构建链优化，不涉及业务 API 或数据模型设计。
|
||||
|
||||
### 架构设计
|
||||
N/A
|
||||
|
||||
### API设计
|
||||
N/A
|
||||
|
||||
### 数据模型
|
||||
N/A
|
||||
|
||||
---
|
||||
|
||||
## 4. 核心场景
|
||||
|
||||
### 场景: push 到发布分支时执行镜像发布
|
||||
**模块**: GitHub Actions / Docker Buildx
|
||||
**条件**: 开发者 push 到 `master` 或 `new-dev`
|
||||
**行为**: checkout 完整源码与子模块，直接用工作区作为 Docker 构建输入，利用 GHA 缓存构建并推送双架构镜像
|
||||
**结果**: 在不减少镜像产物的前提下减少无谓的源码重拉取、上下文与步骤浪费
|
||||
|
||||
---
|
||||
|
||||
## 5. 技术决策
|
||||
|
||||
### optimize-docker-publish-workflow#D001: 改为基于工作区源码构建镜像
|
||||
**日期**: 2026-04-18
|
||||
**状态**: ✅采纳
|
||||
**背景**: 当前 Dockerfile 构建期重新 `git clone`，导致必须用 `CACHEBUST` 强制刷新源码层，缓存收益差且 workflow 内对工作区做的修改无法进入镜像。
|
||||
**选项分析**:
|
||||
| 选项 | 优点 | 缺点 |
|
||||
|------|------|------|
|
||||
| A: 保持构建期 `git clone`，仅修修 workflow 小问题 | 改动小 | 无法根治缓存失效与无效步骤问题 |
|
||||
| B: 直接基于 Actions 工作区 `COPY` 构建 | 能复用 checkout 结果，减少源码重复获取，缓存路径更合理 | 需要同步处理子模块与构建上下文 |
|
||||
**决策**: 选择方案 B
|
||||
**理由**: 这是在不改变发布产物策略的前提下，收益最大且风险可控的提速路径。
|
||||
**影响**: workflow checkout 配置、Dockerfile 源码输入方式、`.dockerignore` 内容
|
||||
|
||||
---
|
||||
|
||||
## 6. 成果设计
|
||||
|
||||
### 设计方向
|
||||
- N/A
|
||||
|
||||
### 视觉要素
|
||||
- N/A
|
||||
|
||||
### 技术约束
|
||||
- **可访问性**: N/A
|
||||
- **响应式**: N/A
|
||||
Reference in New Issue
Block a user