release 模式:新目录 + 配置切换(可回滚)

collect → connect → detect → mkdir / → upload 到该目录
        → 读 configFile → 改写 contextPath 的 docBase → 备份配置 .bak-
        → 新配置写到 .new- 再 mv 原子覆盖 → restart → curl 校验 → 清理旧发布(保留 N 份)

为什么值得:覆盖式发布没有回滚,而回滚在出问题时就是一切。

护栏:找不到匹配的 Context 就拒绝改写并中止(绝不猜、绝不盲改);配置先备份;新配置走临时文件 + mv 原子替换;每步都有报告
无中断:文件先上传到新目录,配置切换前线上仍在跑旧版本;只有 restart 那一下有短暂停机(若 restartOnDeploy: false 且 Context reloadable="true",连停机都没有)
回滚:site_releases 看历史(含当前生效目录),site_rollback 切回上一版(或不指定时自动选上一版),同样先备份配置、改完重启并校验
旧发布目录留在磁盘上直到被 keepReleases 清理,所以回滚随时可用

配置(插件行 `config`)

字段	默认	说明
`dataDir`	`$DSH_HOME/storages/dsh-wei-sitecontrol`	注册表与日志目录
`ringLines`	`5000`	每个站点内存日志行数上限
`stopGraceMs`	`3000`	停止时的宽限期
`autoReclaimOrphans`	`true`	启动时自动清理"命令行与站点自身命令匹配"的遗留进程(见下)
`gitAuthorName` / `gitAuthorEmail`	`DSH Site Manager` / `site-manager@localhost`	内置 git 的提交作者

启动时的孤儿清理(`autoReclaimOrphans`)

站点是 DSH 的子进程,正常关闭时会被干净停掉。但 DSH 被硬杀(断电、任务管理器结束任务、taskkill /F)时没有任何机会执行清理,站点进程就会活下来继续占着端口,导致下次启动失败。

所以插件在启动约 1.5 秒后会做一次清扫,判据严格且保守:

只看已登记站点的端口;
取出占用者的命令行,必须与站点自身的命令匹配(命令里的脚本名/端口号等特征 token 全部出现);
命中才终止(Windows taskkill /T /F);
不匹配的进程绝不碰,只记录为冲突(status.conflict.foreign = true)并在站点日志里写明占用 pid 与命令行,由面板显示红字提示,由人决定是否点「释放端口」。

以下情况一律不杀:命令行含 @deepseek-ai/dsh 或 lib/bin.js(harness 自身)、命令行读不出来、站点没有端口、执行清扫的是 DSH 自己的 pid。

想让插件完全不碰进程,把该字段设为 false,改用面板的「释放端口」按钮或 site_reclaim 工具手动处理。

dsh-wei-sitecontrol

安装

说明文档

release 模式:新目录 + 配置切换(可回滚)

配置(插件行 `config`)

启动时的孤儿清理(`autoReclaimOrphans`)

安装

说明文档

release 模式:新目录 + 配置切换(可回滚)

配置(插件行 config)

启动时的孤儿清理(autoReclaimOrphans)

配置(插件行 `config`)

启动时的孤儿清理(`autoReclaimOrphans`)