2026-05-21-14-35-20 合并Docker部署Release记录
This commit is contained in:
58
工程分析/实现方案-2026-05-21-14-35-20.md
Normal file
58
工程分析/实现方案-2026-05-21-14-35-20.md
Normal file
@@ -0,0 +1,58 @@
|
||||
# 实现方案：合并 Docker 三版本 Gitea Release
|
||||
|
||||
实现方案文档路径：`工程分析/实现方案-2026-05-21-14-35-20.md`
|
||||
|
||||
## 修改目标
|
||||
|
||||
将 Gitea 上三个 Docker 部署 Release 合并为一个整合 Release，并在该 Release 中挂载三个命名清晰的部署附件。
|
||||
|
||||
## 涉及路径
|
||||
|
||||
- `/home/wkmgc/Desktop/ReVoxelSeg_DICOM_Docker`
|
||||
- `工程分析/需求分析-2026-05-21-14-35-20.md`
|
||||
- `工程分析/实现方案-2026-05-21-14-35-20.md`
|
||||
- `工程分析/测试方案-2026-05-21-14-35-20.md`
|
||||
- `工程分析/经验记录.md`
|
||||
|
||||
## 技术路线
|
||||
|
||||
1. 使用独立 Docker 仓库中已有三个 release tag，通过 `git archive` 生成三个部署压缩包。
|
||||
2. 对通用版 tag 做固定环境信息搜索，确认没有泄露当前 FRPC 与域名配置。
|
||||
3. 创建整合 tag `revoxelseg-docker-all-v2026.05.21` 并推送到 Gitea。
|
||||
4. 通过 Gitea API 创建单个整合 Release。
|
||||
5. 上传三个附件：
|
||||
- 本机直接部署包
|
||||
- 威联通 NAS 直接部署包
|
||||
- 通用部署包
|
||||
6. 确认整合 Release 附件完整后，再删除旧三个 Release 记录。
|
||||
|
||||
## 执行步骤
|
||||
|
||||
- 生成 `release-assets/` 临时附件目录。
|
||||
- 从三个 tag 归档生成 `.tar.gz` 文件。
|
||||
- 校验压缩包目录结构与关键文件。
|
||||
- 创建并推送整合 tag。
|
||||
- 调用 Gitea Releases API 创建整合发布。
|
||||
- 逐个上传附件并检查资产列表。
|
||||
- 删除旧 release id 或通过 tag 查询后删除。
|
||||
- 验证本地与公网服务。
|
||||
- 更新测试方案与经验记录。
|
||||
- 仅提交本次工程分析文档。
|
||||
|
||||
## 兼容性与回滚方案
|
||||
|
||||
- 原三个 tag 与分支不删除，若整合 Release 出现问题，可基于 tag 重新生成附件或恢复旧 Release。
|
||||
- 删除旧 Release 记录只影响 Gitea 页面展示，不影响 git 历史。
|
||||
- 若附件上传失败，不删除旧 Release，待上传成功后再清理。
|
||||
|
||||
## 预计文件变更
|
||||
|
||||
- 新增三份本次工程分析文档。
|
||||
- 追加 `工程分析/经验记录.md`。
|
||||
- 独立 Docker 仓库仅可能新增未跟踪临时附件目录，不纳入提交。
|
||||
|
||||
## 提交与部署策略
|
||||
|
||||
- 主工程提交信息包含时间戳：`2026-05-21-14-35-20 合并Docker部署Release记录`。
|
||||
- 独立 Docker 仓库只推送整合 tag，不提交临时附件。
|
||||
- 发布后验证 `http://127.0.0.1:4000/api/health` 与 `https://revoxel.huijutec.cn/`。
|
||||
71
工程分析/测试方案-2026-05-21-14-35-20.md
Normal file
71
工程分析/测试方案-2026-05-21-14-35-20.md
Normal file
@@ -0,0 +1,71 @@
|
||||
# 测试方案：合并 Docker 三版本 Gitea Release
|
||||
|
||||
测试方案文档路径：`工程分析/测试方案-2026-05-21-14-35-20.md`
|
||||
|
||||
## 静态检查
|
||||
|
||||
- 检查独立 Docker 仓库存在三个 release tag。
|
||||
- 检查通用版 tag 中不包含固定 FRPC 服务端、token、远端端口、当前公网域名或内网访问地址。
|
||||
- 检查生成附件中包含 `Dockerfile`、`docker_compose.yaml`、`README.md`、`WebSite/`、默认 DICOM 与 STL 数据。
|
||||
|
||||
## 构建检查
|
||||
|
||||
- 本次不重新构建镜像，沿用当前已验证的 Docker 独立程序内容。
|
||||
- 使用 `tar -tzf` 检查三份压缩包结构可读。
|
||||
|
||||
## 关键业务场景验证
|
||||
|
||||
- Gitea 整合 Release 创建成功。
|
||||
- 整合 Release 中能看到三个命名不同的附件。
|
||||
- 旧三个分散 Release 记录被清理，避免 Releases 页面重复。
|
||||
|
||||
## 医学影像数据相关边界验证
|
||||
|
||||
- 附件中保留默认 `Head_CT_DICOM/` 与 `Head_CT_ReConstruct/`，确保新环境可直接部署演示数据。
|
||||
- 通用版不含当前固定公网 FRPC 配置，避免错误复用到其他医学影像部署环境。
|
||||
|
||||
## 部署验证
|
||||
|
||||
- 验证本机服务健康接口：`http://127.0.0.1:4000/api/health`。
|
||||
- 验证公网入口：`https://revoxel.huijutec.cn/`。
|
||||
|
||||
## Git/Gitea 备份验证
|
||||
|
||||
- 确认整合 tag 已推送。
|
||||
- 确认 Gitea Release API 返回整合 Release 与三个附件。
|
||||
- 主工程只提交本次工程分析文档和经验记录。
|
||||
|
||||
## 风险与回归关注点
|
||||
|
||||
- 旧 Release 删除应在新 Release 附件上传完成后执行。
|
||||
- 大附件上传完成后必须通过 API 查询附件名称和数量，不只依赖命令退出码。
|
||||
- 文档提交时避免把历史删除和未跟踪软著、医学数据混入 commit。
|
||||
|
||||
## 实际验证结果
|
||||
|
||||
- 已生成三个附件：
|
||||
- `ReVoxelSeg_DICOM_Docker_machine_direct_v2026.05.21.tar.gz`，约 190MB。
|
||||
- `ReVoxelSeg_DICOM_Docker_nas_direct_v2026.05.21.tar.gz`，约 190MB。
|
||||
- `ReVoxelSeg_DICOM_Docker_generic_v2026.05.21.tar.gz`，约 190MB。
|
||||
- `tar -tzf` 校验三份附件均包含根目录 `Dockerfile`、`docker_compose.yaml`、`README.md`、`WebSite/`、`Head_CT_DICOM/`、`Head_CT_ReConstruct/`。
|
||||
- 对通用版 tag 使用 `git grep -I` 搜索固定环境字符串，未发现 `82.157.255.195`、`en.xjtu.edu.cn`、`10008`、`revoxel.huijutec.cn`、`192.168.3.11`、`192.168.31.7`。
|
||||
- 已创建并推送整合 tag：`revoxelseg-docker-all-v2026.05.21`。
|
||||
- 已创建 Gitea 整合 Release：
|
||||
- `https://gitea.huijutec.cn/admin/REVOXELSEG_DICOM/releases/tag/revoxelseg-docker-all-v2026.05.21`
|
||||
- Release ID：`44`
|
||||
- 已上传三个附件，Gitea API 读回资产列表数量为 3：
|
||||
- `ReVoxelSeg_DICOM_Docker_generic_v2026.05.21.tar.gz`
|
||||
- `ReVoxelSeg_DICOM_Docker_machine_direct_v2026.05.21.tar.gz`
|
||||
- `ReVoxelSeg_DICOM_Docker_nas_direct_v2026.05.21.tar.gz`
|
||||
- 上传通用包时曾出现一次 `502`，`curl --retry` 自动重传后成功。
|
||||
- 已删除旧三个分散 Release 记录：
|
||||
- `revoxelseg-docker-machine-v2026.05.21`，原 Release ID `41`。
|
||||
- `revoxelseg-docker-nas-v2026.05.21`，原 Release ID `42`。
|
||||
- `revoxelseg-docker-generic-v2026.05.21`，原 Release ID `43`。
|
||||
- Gitea API 复查 Docker 发布相关条目，仅剩整合 Release：`revoxelseg-docker-all-v2026.05.21`。
|
||||
- Docker 运行验证：
|
||||
- `revoxelseg_web` 状态为 `Up ... (healthy)`，端口 `0.0.0.0:4000->4000`。
|
||||
- `revoxelseg_frpc` 状态为 `Up`。
|
||||
- 服务验证：
|
||||
- `http://127.0.0.1:4000/api/health` 返回 `{"ok":true,"service":"revoxelseg-dicom"}`。
|
||||
- `https://revoxel.huijutec.cn/` 返回 `HTTP/2 200`。
|
||||
18
工程分析/经验记录.md
18
工程分析/经验记录.md
@@ -1549,3 +1549,21 @@ C. 解决问题方案
|
||||
D. 后续如何避免问题
|
||||
|
||||
以后发布多部署形态时，不要只改 Release 文案；应使用不同 tag 固化不同文件状态。包含具体环境配置的版本可以保留当前内网、域名和 FRPC 信息；通用版本必须使用环境变量或占位模板，并在发布前全目录搜索确认没有遗留服务地址、token、远端端口和固定域名。创建 Gitea Release 后，应再通过 API 或页面确认 Release、tag 和目标提交一致。
|
||||
|
||||
## 2026-05-21-14-35-20 多部署包应合并到单个 Release 的多个附件
|
||||
|
||||
A. 具体问题
|
||||
|
||||
用户指出机器直接部署版、NAS 直接部署版和通用版分别创建三个 Gitea Release 后，发布页面显得杂乱，查找和下载都不够直观；用户希望合并为一个发布项，并用不同附件名称区分部署场景。
|
||||
|
||||
B. 产生问题原因
|
||||
|
||||
此前把“部署场景”映射成了“Release 条目”，虽然 tag 追溯清晰，但 Gitea Releases 页面会出现多个同日期、同系统、只因部署配置不同而拆开的发布项。对使用者来说，版本概念应该只有一个，部署差异更适合作为同一 Release 下的资产附件呈现。
|
||||
|
||||
C. 解决问题方案
|
||||
|
||||
保留原三个部署 tag 和分支作为源码追溯锚点，新增整合 tag `revoxelseg-docker-all-v2026.05.21` 并创建单个整合 Release。使用 `git archive` 从三个 tag 分别生成本机直接部署版、威联通 NAS 直接部署版和通用版 `.tar.gz` 附件，上传到同一个 Release；确认三个附件均可从 Gitea API 读回后，再删除旧的三个分散 Release 记录。通用版发布前用文本搜索确认未包含固定 FRPC、域名和内网配置。
|
||||
|
||||
D. 后续如何避免问题
|
||||
|
||||
后续同一版本存在多个部署形态、系统架构或环境模板时，优先使用“一个 Release + 多个命名附件”的发布模型；只有当版本号、功能内容或源码状态确实不同，才拆成多个 Release。删除旧 Release 前必须先确认新 Release 的附件数量、名称和大小均已从 Gitea API 读回，避免页面清理造成发布物短暂缺失。
|
||||
|
||||
56
工程分析/需求分析-2026-05-21-14-35-20.md
Normal file
56
工程分析/需求分析-2026-05-21-14-35-20.md
Normal file
@@ -0,0 +1,56 @@
|
||||
# 需求分析：合并 Docker 三版本 Gitea Release
|
||||
|
||||
开始时间：2026-05-21-14-35-20
|
||||
|
||||
## 原始需求摘要
|
||||
|
||||
用户认为当前在 Gitea 中分别发布“机器直接部署版本”“NAS 直接部署版本”“通用版本”三个 Release 过于杂乱，希望将三个发布合并成一个 Release，同时通过附件名称区分不同部署包。
|
||||
|
||||
## 业务目标
|
||||
|
||||
- Gitea Releases 页面只保留一个面向 Docker 部署的整合发布项。
|
||||
- 整合发布项内包含三个部署附件：本机直接部署版、威联通 NAS 直接部署版、通用版。
|
||||
- 三个附件通过文件名清晰区分部署场景。
|
||||
- 保留已有 tag/分支作为源码锚点，降低回滚和追溯风险。
|
||||
|
||||
## 输入与输出
|
||||
|
||||
输入：
|
||||
|
||||
- 独立 Docker 程序仓库：`/home/wkmgc/Desktop/ReVoxelSeg_DICOM_Docker`
|
||||
- 现有三个发布 tag：
|
||||
- `revoxelseg-docker-machine-v2026.05.21`
|
||||
- `revoxelseg-docker-nas-v2026.05.21`
|
||||
- `revoxelseg-docker-generic-v2026.05.21`
|
||||
- Gitea 仓库：`admin/REVOXELSEG_DICOM`
|
||||
|
||||
输出：
|
||||
|
||||
- 一个新的整合 Release。
|
||||
- 三个独立命名的 `.tar.gz` 附件。
|
||||
- 删除旧的三个分散 Release 记录。
|
||||
- 本次工程分析文档与经验记录备份 commit。
|
||||
|
||||
## 影响范围
|
||||
|
||||
- Gitea Release 展示与附件组织方式。
|
||||
- 独立 Docker 仓库 tag 与发布附件，不改业务代码。
|
||||
- 主工程 `工程分析/` 文档。
|
||||
|
||||
## 关键约束
|
||||
|
||||
- 不把 `工程分析/`、软著材料等非部署内容放入 Docker 发布附件。
|
||||
- 通用版附件不得包含当前环境固定 FRPC 地址、token、端口、域名等信息。
|
||||
- 不提交或回滚工作区内与本次无关的历史删除、未跟踪医学数据、软著目录。
|
||||
- 发布整理完成后继续验证本机 `4000` 服务和公网域名可访问。
|
||||
|
||||
## 风险点
|
||||
|
||||
- 大体积附件上传失败或上传不完整。
|
||||
- 删除旧 Release 前若新 Release 未成功上传附件，会导致页面暂时缺少可下载包。
|
||||
- Gitea API 失败时需要保留旧 Release，避免发布物丢失。
|
||||
|
||||
## 默认假设
|
||||
|
||||
- 用户要求“合并成一个发布”指删除三个旧 Release 页面记录，但保留对应 tag/分支用于追溯。
|
||||
- 一个整合 Release 的 tag 使用 `revoxelseg-docker-all-v2026.05.21`。
|
||||
Reference in New Issue
Block a user