14 个迁移 App 未固化
gottenergy 的 14 个非标准 app 通过
git clone手动装进 bench 容器，容器重建后全部丢失。未走 Press 标准 Build 管道固化到 Docker 镜像。
1. 归属
| 问题 | 答案 |
|---|---|
| 属于哪个仓库？ | app 源码在各 GitHub 仓库。操作的是 bench 容器内的 /home/frappe/frappe-bench/apps/ |
| 在容器内路径？ | bench 容器内 apps 目录 + Python site-packages 的 .pth 文件 |
| 在构建链的哪一步？ | 跳过了。标准流程是 App Source → Release → Release Group → Build → Deploy。这些 app 走了捷径 git clone |
2. 功能解释
Press 的标准 App 安装流程：
App 注册 → App Source（指向 GitHub repo + branch）→ App Release（git commit hash）→ 加入 Release Group → Deploy Candidate → Build（打入 Docker 镜像）→ Deploy（新 bench 容器自带 app）
手动 clone 跳过了什么：
整个 Build 阶段。app 源码在容器文件系统里，没在镜像里。容器重建 → 源码消失。
为什么当时不走标准流程？
两个原因：
- 14 个 app 很多没有 version-16 分支（只有 develop），
bench get-app找不到对应分支 - Python 3.14 TOML 严格解析历史上中断过 Kai 的 Build
- gohighlevel 仓库不确定是否 public
当时的选择是”先跑通，下次重建一起固化”。
5. 性质判断
技术债。当前容器稳定运行所以没触发，但重建就丢。
6. 正确做法
SolarFlow Press-B 全走标准 Build 管道。每个 app：App Source → Release → Build → 镜像固化。没有历史包袱，不需要手动 clone。
7. 影响范围
- 容器重建后 14 个 app 全部消失
- 固化时的风险：Python TOML 解析 + gohighlevel 仓库可访问性