CI 里更新 DeepSeek Harness 与 DSH plugin：非交互、锁版本与缓存

CI 里更新 DeepSeek Harness 与手工更新是两件事：没有交互终端（提示一出现就挂死）、要求可复现（版本不能自己漂）、要求快（每次重装的时间会被乘以构建次数）。 所以正确的做法不是把手工命令原样塞进 YAML，而是先选一种「版本从哪来」的方案（钉版本 / 跟随最新 + 快照 / 镜像承载），再补上非交互与失败即退出的写法，最后把缓存接上。DSH plugin 在 CI 里还多一层：它们的版本也要一起钉，否则本体锁住了、插件却飘，问题照样复现不了。

CI 里更新 DeepSeek Harness 和手工更新差在哪：三种方案

一句话结论：差别只有三条——没有终端、不能容忍版本随机、时间成本被放大；三条都指向同一件事：把版本变成显式输入。

方案 A：钉版本安装 / 升级（可复现，推荐）

一句话结论：把本体与 DSH plugin 的版本都写死在配置里，升级 = 改版本号并提交——这是唯一能回答「这次跑的是哪一版」的方案。

1. 本体钉版本安装：

npm i -g @deepseek-ai/dsh@0.2.0-rc.2
dsh --version        # 预期：与钉住的版本一致

2. 插件清单也钉版本，写成一个可执行的清单文件（示例）：

# plugins.txt 每行一个「包名@版本」
dsh plugin add <插件包名>@<版本>

3. 升级是一个显式动作：改版本号 → 提交 → 流水线重跑；不要在 CI 里写「永远装最新」。
4. 保留验证过的组合记录：本体版本 + 插件版本写成一行，回退时照抄上一行即可（这一点在 多台机器统一更新 DeepSeek Harness 里同样适用）。

方案 B：跟随最新 + 记录快照（跟随型）

一句话结论：确实需要「总跑最新」时，也要把这次实际拿到的版本打印并归档——把不可复现换成可追溯。

1. 安装最新版，但立即记录实际版本：

npm i -g @deepseek-ai/dsh
dsh --version | tee version.txt      # 归档进构建产物

2. 把快照当构建结果的一部分：版本文件、已装 DSH plugin 清单都留档，出问题能比对「上次绿的时候是什么版本」。
3. 配一个告警：版本变化时通知（而不是静默跟随），让「上游发新版」这件事可见。
4. 取舍说明：这条方案放弃了可复现，换取了「第一时间发现兼容问题」——适合你本来就在跟踪上游节奏的仓库。

方案 C：用镜像承载版本（CI 最省时）

一句话结论：把本体与常用 DSH plugin 预置进自建镜像，流水线只拉镜像——版本天然钉住，安装时间基本归零。

1. 镜像里钉版本 + 预置插件（写法见 DeepSeek Harness 容器化安装 的方案 C）。
2. CI 直接用镜像跑测试，不再安装：少了下载与编译，构建时间稳定。
3. 升级 = 构建新镜像并推私有仓库，旧镜像留作回退点——这比改脚本里的版本号更容易回滚。
4. 注意缓存与卷：流水线里把数据目录设成临时目录（跑完即弃），避免把上一次的会话状态带进这次测试。

DSH plugin 在 CI 里的非交互与「失败即退出」：三种写法

一句话结论：非交互靠三件事——显式的环境变量、不触发输入的参数、以及超时兜底；失败即退出靠 set -e 与显式判断退出码。

1. 写法一：显式声明非交互环境（示例）：

export CI=true
set -euo pipefail        # 任一命令失败即终止，避免带病继续

2. 写法二：命令层面避免交互：不要使用会提问的参数（例如交互式确认、编辑器型参数）；需要「全自动」时优先用具确定性输入的等价形式。
3. 写法三：超时兜底，防止挂死整条流水线：

timeout 900 npm i -g @deepseek-ai/dsh@0.2.0-rc.2
# 预期：超时后以非零码退出，流水线立刻失败而不是卡住

4. 别忽略退出码：把「安装」与「校验」分成两步，校验失败也要让流水线红——只装不验等于没测。

DeepSeek Harness CI 缓存与提速：三种做法

一句话结论：缓存按收益排序是「镜像 > 包缓存 > 按哈希跳过安装」；能上镜像就上镜像。

1. 镜像预置（收益最大）：本体与高频 DSH plugin 都在镜像里，运行阶段零安装。
2. 缓存 npm 缓存目录，用锁文件或清单哈希做缓存键：

# 伪代码示意：缓存键由清单文件哈希构成
key: dsh-${{ hashFiles('plugins.txt', 'package-lock.json') }}

3. 按哈希跳过安装：清单没变就不重装，只做校验（快但要小心「缓存里是坏产物」的情况，定期清理一次）。
4. 代理与镜像源：内网流水线记得把 registry 指到私有源，否则每次都在公网拉（见 离线与内网里用 npx @deepseek-ai/dsh web）。

跑完必须做的版本与 DSH plugin 校验

一句话结论：安装退出码为 0 不等于升级成功——必须验证「版本对不对、插件齐不齐、服务能不能起」。

1. 版本校验：打印 dsh --version 与实际可执行路径，和预期比对。
2. 插件清单校验：列出已装列表并核对数量与版本；数量少了说明有插件没装上。
3. 冒烟校验：起一次服务并确认端口可访问（dsh web 起得来即最小可用）。
4. 留档：把上面三项的输出写进构建产物，出问题时有据可查。
5. 顺手看数据目录：CI 里 DSH_HOME 指向临时目录更干净，避免状态污染下次构建。

DSH plugin CI 排查注意事项

一句话结论：CI 里的失败先分「挂死」与「报错」两类——挂死几乎都是交互提示，报错才去看版本与源。

1. 挂死→ 查是否有交互提示、是否缺 CI=true、是否缺超时兜底。
2. 装不上→ 查源与包名版本是否存在（内网还查私有源是否同步）。
3. 版本没变→ 检查是不是装到了另一个入口（全局 vs npx），这与 npx 与全局混装的版本漂移 同源。
4. 插件缺→ 逐项核对清单，而不是重试。
5. 偶发失败→ 先怀疑缓存命中了坏产物，清缓存重跑一次定位。
6. 修复状态如实：本文方案基于 npm 可复现安装机制与官方 CLI 的升级/插件子命令说明；dsh 具体参数名以流水线里 dsh --help 的输出为准，DeepSeek Harness 迭代较快，建议把版本号与参数一起写进仓库文档。

CI 里要装的插件清单，先在 DSH Plugin Hub 里敲定再写进流水线配置，比在流水线里边翻边装可靠得多。

来源：apps/cli/README.md、npm Docs · npm ci、npm @deepseek-ai/dsh。