opendance-web

22 Commits 2 Branches 17 Tags

2 Commits

Include renames

Author	SHA1	Message	Date
zijunchiang	caca7672cb	fix(release): 修复发布包缺失 storage 模块，并加入产物完整性校验用户实测：用发布包部署后启动报 MODULE_NOT_FOUND at dist/models/models.module.js:13 require('../storage/storage.module') 根因：package-release.sh 的 rsync 用了 --exclude 'storage'。该模式匹配任意层级的同名目录，把源码目录 src/storage/ 与编译产物 dist/storage/ 一并排除——发布包里完全没有 storage 模块，服务必然起不来。这与第一阶段 .gitignore 里 'storage/' 误伤 src/storage/ 是同一类错误，本项目第二次踩到。修复： - 排除模式全部锚定到 web-server 根：'/storage/'、'/data/'、'/tmp/'、 '/.env'、'/admin/'，不再匹配嵌套同名目录 - 新增产物完整性校验（打包后自动执行，失败即删除压缩包）： src 下每个 .ts 必须有对应 dist/*.js；关键文件清单齐全；不得混入 node_modules / 真实 .env / 运行时存储 / keystore - ctl.sh 补上缺失的 warn 函数（line 120: warn: command not found）实测： - 对照实验：排除模式改回 'storage' 后校验准确报出缺少 dist/storage/storage.module.js 并删除压缩包，退出码 1 - 新包端到端：解压 → npm ci --omit=dev（213 包）→ 启动 → /health 200、 MariaDB 已连接、迁移 0、catalog/songs/models/motions 全部 200	2026-09-15 00:54:22 +08:00
zijunchiang	c092b833fb	fix(deploy): 支持无 systemd 的环境，并修复降级路径的两个真实缺陷用户实测：服务器没有 systemctl，install.sh 直接报错退出。原错误信息本身也是错的（建议 SKIP_NGINX=1，但那只跳过 nginx，仍走 systemctl）。进程管理改为四层降级： systemd → OpenRC → SysVinit → nohup 后台进程（deploy/ctl.sh） - 新增 deploy/ctl.sh：start/stop/restart/status/logs，PID 文件 + 进程名双重判定 - 新增 deploy/openrc/opendance-api、deploy/initd/opendance-api - 无 init 系统时写 crontab @reboot 实现开机自启 - uninstall.sh 同步支持四种模式清理（原先只处理 systemd，会留下运行中的进程） - 汇总输出按实际初始化系统给出对应运维命令测试中发现并修复降级路径的两个真实缺陷： 1. nohup 无法调用 shell 函数实测退出码 127 且什么都不执行（nohup 是外部命令，只能执行可执行文件）。这会让无 systemd 的降级路径完全失效——服务根本起不来。改为按 runuser / setpriv / su 显式拼接成外部命令后再 nohup。另加启动后 1 秒存活检测，失败立即打印日志，不再白等 30 秒。 2. find_pids 在无进程时返回一个空格在空输入下仍会执行一次 echo，输出空行，最终得到 " "；调用方 [ -n ... ] 会判为「有进程」，导致 start 直接跳过、status 谎报运行中。改为纯 bash 拼接，空时返回空串。实测（真实 API 进程，端口 3100）： start → 健康检查 200，PID 正确重复 start → 识别已在运行，进程数保持 1 status → 运行中 restart → 新 PID，健康检查 200 stop → 无残留进程，端口释放无 process 时 find_pids 返回空串，is_running=false	2026-09-15 00:34:52 +08:00

Author

SHA1

Message

Date

zijunchiang

caca7672cb

fix(release): 修复发布包缺失 storage 模块，并加入产物完整性校验

用户实测：用发布包部署后启动报 MODULE_NOT_FOUND
  at dist/models/models.module.js:13  require('../storage/storage.module')

根因：package-release.sh 的 rsync 用了 --exclude 'storage'。该模式匹配
**任意层级**的同名目录，把源码目录 src/storage/ 与编译产物 dist/storage/
一并排除——发布包里完全没有 storage 模块，服务必然起不来。
这与第一阶段 .gitignore 里 'storage/' 误伤 src/storage/ 是同一类错误，
本项目第二次踩到。

修复：
- 排除模式全部锚定到 web-server 根：'/storage/'、'/data/'、'/tmp/'、
  '/.env'、'/admin/'，不再匹配嵌套同名目录
- 新增产物完整性校验（打包后自动执行，失败即删除压缩包）：
  src 下每个 .ts 必须有对应 dist/*.js；关键文件清单齐全；
  不得混入 node_modules / 真实 .env / 运行时存储 / keystore
- ctl.sh 补上缺失的 warn 函数（line 120: warn: command not found）

实测：
- 对照实验：排除模式改回 'storage' 后校验准确报出缺少
  dist/storage/storage.module.js 并删除压缩包，退出码 1
- 新包端到端：解压 → npm ci --omit=dev（213 包）→ 启动 → /health 200、
  MariaDB 已连接、迁移 0、catalog/songs/models/motions 全部 200

2026-09-15 00:54:22 +08:00

zijunchiang

c092b833fb

fix(deploy): 支持无 systemd 的环境，并修复降级路径的两个真实缺陷

用户实测：服务器没有 systemctl，install.sh 直接报错退出。

原错误信息本身也是错的（建议 SKIP_NGINX=1，但那只跳过 nginx，仍走 systemctl）。

进程管理改为四层降级：
  systemd → OpenRC → SysVinit → nohup 后台进程（deploy/ctl.sh）
- 新增 deploy/ctl.sh：start/stop/restart/status/logs，PID 文件 + 进程名双重判定
- 新增 deploy/openrc/opendance-api、deploy/initd/opendance-api
- 无 init 系统时写 crontab @reboot 实现开机自启
- uninstall.sh 同步支持四种模式清理（原先只处理 systemd，会留下运行中的进程）
- 汇总输出按实际初始化系统给出对应运维命令

测试中发现并修复降级路径的两个真实缺陷：

1. nohup 无法调用 shell 函数
    实测退出码 127 且什么都不执行
   （nohup 是外部命令，只能执行可执行文件）。
   这会让无 systemd 的降级路径完全失效——服务根本起不来。
   改为按 runuser / setpriv / su 显式拼接成外部命令后再 nohup。
   另加启动后 1 秒存活检测，失败立即打印日志，不再白等 30 秒。

2. find_pids 在无进程时返回一个空格
    在空输入下仍会执行一次 echo，输出空行，
   最终得到 " "；调用方 [ -n ... ] 会判为「有进程」，
   导致 start 直接跳过、status 谎报运行中。改为纯 bash 拼接，空时返回空串。

实测（真实 API 进程，端口 3100）：
  start → 健康检查 200，PID 正确
  重复 start → 识别已在运行，进程数保持 1
  status → 运行中
  restart → 新 PID，健康检查 200
  stop → 无残留进程，端口释放
  无 process 时 find_pids 返回空串，is_running=false

2026-09-15 00:34:52 +08:00