31 lines
3.2 KiB
Markdown
31 lines
3.2 KiB
Markdown
# 在线更新发布来源
|
|
|
|
`release-manifest.json` 是唯一的正式产品发布记录。页面检测、任务目标、updater 执行以及没有 updater 的旧 Watchtower 部署均读取它。`APP_VERSION` 与 `/app/version` 只表示当前运行版本，用于展示和更新结果确认；`APP_VERSION_CHECK_BASE_URL` 不再参与新版检测。
|
|
|
|
默认从部署仓库 main 的发布清单读取，无需先升级某台公开 API 服务。自建发布渠道使用 `UPDATE_MANIFEST_URL`；离线部署明确设置 `UPDATE_MANIFEST_SOURCE=local`，后端和 updater 读取同一个挂载文件。读取失败时显示无法检查更新，不使用过期文件代替正式版本。
|
|
|
|
发布时先完成后端和网页的同一版本镜像推送，然后生成整套记录：
|
|
|
|
```sh
|
|
python3 scripts/prepare-product-release.py --version 3.24.0.20261008.1 \
|
|
--policy system-update/release-manifest.json \
|
|
--output system-update/release-manifest.json
|
|
```
|
|
|
|
版本只从镜像实际发布信息读取，不另行人工同步网页版本或 API 运行版本。工具验证服务器和网页镜像的版本标签、linux/amd64 平台、三组件完整性及远程 digest，全部通过后才原子写入。网关未变化时保留上一正式 digest；有变化时显式传入 `--gateway-ref`。发布策略由 `--policy` 指定，必须在发布审查中确认，工具不推断新版本的回滚安全性。生成文件不等于已经发布，提交并发布该记录后才向部署开放新版。
|
|
|
|
旧 Watchtower 仍执行其原有可变镜像标签，不能按清单锁定 digest。因此发布前须确保其使用的服务器/网页标签与清单版本一致。任务严格检查核心服务恢复和目标运行版本，不会把请求收到或版本不一致当作升级成功。
|
|
|
|
## 更新状态
|
|
|
|
- 提交前未能连接更新服务：尚未提交，提示管理员检查容器、地址和授权。单凭连接错误不能断言容器已经退出。
|
|
- 旧服务在线、没有历史/进度接口：可执行更新；请求发出后明确提示可能仍在下载或安装。
|
|
- 已发送但没有收到回复：保留原任务和请求标识，只查询，不自动再次提交。
|
|
- 执行结束但核心服务未恢复、或版本不一致：说明具体未确认项，不显示成功。
|
|
|
|
进度窗口始终可以关闭，关闭不取消服务端任务。仍在前台查询时可以通过“查看更新进度”重新打开；刷新按原任务恢复。旧 Watchtower 前台等待最多五分钟，之后保留“结果待确认”，服务端继续检查原任务。受管更新有独立的较长执行窗口，但窗口同样随时可关闭。
|
|
|
|
历史旧任务没有发布标识、目标来自旧运行版本接口时，只在请求已发送、所有核心服务可用且实际安装版本与正式发布记录完全相等时修正结果，保留原目标供核对。带发布标识的新任务和受管任务仍严格匹配原目标，不能用任意更高版本冒充成功。
|
|
|
|
旧浏览器保存的兼容记录没有任务接口时，同样重新核对当前运行版本和正式发布信息；只有两者完全一致且高于旧目标，才确认新版已安装。无法核对时保留待确认，不接受任意更高版本。
|