Update DeepSeek Harness in CI: DSH plugin versions

Updating DeepSeek Harness in CI is a different problem from updating it by hand: there is no terminal (so a single prompt hangs the job), you need reproducibility (versions must not drift), and time is multiplied by build count. Copying interactive commands into YAML therefore fails in predictable ways. Pick a version-source strategy first — pinned versions, latest-with-snapshot, or a version-carrying image — then add non-interactive and fail-fast patterns, then caching. DSH plugin packages add one more layer: pin their versions too, or you lock the CLI and still cannot reproduce failures because plugins drift.

Why updating DeepSeek Harness in CI differs from manual updates

Bottom line: three differences — no terminal, no tolerance for random versions, and amplified time cost. All three point to making the version an explicit input.

Option A: pinned versions (reproducible, recommended)

Bottom line: write the CLI and DSH plugin versions into configuration, and treat upgrading as editing that version and committing. This is the only approach that answers "which version ran."

1. Install the pinned CLI:

npm i -g @deepseek-ai/dsh@0.2.0-rc.2
dsh --version        # expected: matches the pinned version

2. Pin the plugin list in an executable manifest:

# plugins.txt — one package@version per line
dsh plugin add <plugin-package>@<version>

3. Make upgrading an explicit commit: change the version, commit, re-run. Never write "always install latest" in CI.
4. Record validated combinations: one line per CLI plus plugin version set. Rollback means copying the previous line (the same practice applies in aligning DeepSeek Harness across machines).

Option B: latest plus snapshot (tracking upstream)

Bottom line: if you genuinely need "always latest," print and archive the version you actually got — trade reproducibility for traceability.

1. Install latest but capture the result immediately:

npm i -g @deepseek-ai/dsh
dsh --version | tee version.txt      # archive as a build artifact

2. Treat the snapshot as a build output: version file and installed DSH plugin list both archived, so you can compare against the last green run.
3. Alert on version changes instead of adopting them silently, making upstream releases visible.
4. Stated cost: you give up reproducibility in exchange for early warning of compatibility problems.

Option C: images carry the DeepSeek Harness version (fastest jobs)

Bottom line: bake the CLI and common DSH plugin packages into an internal image and have the pipeline pull it. Versions are pinned by construction and install time drops to nearly zero.

1. Pin inside the image and preset plugins (see Path C in installing DeepSeek Harness in Docker).
2. Run tests directly from the image — no download, no compile, stable build times.
3. Upgrading means building and publishing a new tag; keep the old tag as the rollback point. This is easier to roll back than editing version numbers in scripts.
4. Watch volumes: point the data directory at a temporary path in CI so previous session state never leaks into the current test.

Non-interactive and fail-fast patterns for DeepSeek Harness

Bottom line: non-interactive needs an explicit environment variable, input-free flags and a timeout; fail-fast needs set -e plus explicit exit-code checks.

1. Pattern one: declare the non-interactive environment (example):

export CI=true
set -euo pipefail        # stop on the first failure instead of continuing broken

2. Pattern two: avoid interactive flags at the command level. Prefer deterministic equivalents over anything that prompts or opens an editor.
3. Pattern three: wrap with a timeout so a hang cannot stall the job:

timeout 900 npm i -g @deepseek-ai/dsh@0.2.0-rc.2
# expected: exits non-zero on timeout, failing the pipeline immediately

4. Never ignore exit codes: separate install and verify steps, and fail the pipeline when verification fails. Installing without verifying is not a test.

Caching options for DeepSeek Harness CI jobs

Bottom line: by payoff, images beat package caching, which beats skipping by hash. Use an image when you can.

1. Image presets (largest win): the CLI and frequent DSH plugin packages live in the image; the job installs nothing.
2. Cache the npm cache directory, keyed by a lockfile or manifest hash:

# illustrative: key derived from manifest hashes
key: dsh-${{ hashFiles('plugins.txt', 'package-lock.json') }}

3. Skip installation when nothing changed, but occasionally purge the cache to avoid stale bad artifacts.
4. Point the registry at your private source on intranet runners, or every job hits the public internet (see running npx @deepseek-ai/dsh web offline).

Post-run verification for DeepSeek Harness and DSH plugin

Bottom line: a zero exit code is not success. Verify the version, the plugin set, and that the service starts.

1. Version check: print dsh --version and the resolved executable path, then compare.
2. Plugin list check: list installed plugins and compare counts and versions; missing entries mean a plugin did not install.
3. Smoke check: start the service once and confirm the port responds — dsh web starting is the minimum usable proof.
4. Archive all three outputs as build artifacts for later comparison.
5. Check DSH_HOME: a temporary directory per run keeps state from leaking between builds.

DSH plugin CI troubleshooting

Bottom line: split failures into "hangs" and "errors." Hangs are almost always prompts; errors are versions and sources.

1. Hang — check for prompts, a missing CI variable, or a missing timeout.
2. Will not install — check the source and whether the package version exists (and whether the private source synced it).
3. Version unchanged — check whether the install hit a different entry point, the same root cause as npx versus global drift.
4. Plugin missing — check the manifest item by item instead of retrying.
5. Intermittent failure — suspect a stale cached artifact; clear the cache and re-run to confirm.
6. Repair status, stated honestly: these options follow npm's reproducible install mechanics and the official CLI's upgrade and plugin subcommands. Confirm flag names via dsh --help inside the pipeline, and record both versions and flags in your repository documentation.

Sources: apps/cli/README.md, npm Docs · npm ci, npm @deepseek-ai/dsh.