dsh-ci-runner
触发 GitHub Actions 工作流运行和本地测试流水线，实时传回日志；失败时将日志末尾内容交给 DeepSeek，以 Markdown 格式进行根因诊断。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:JohnXu22786/ci-runner#75e0e1cd6180a8412e95cb62d335082f2b095e25Ci Runner 以 dsh-ci-runner 发布，当前版本为 0.1.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
点击下方 Badge 复制 Markdown，粘贴到 README 即可。
验证 package.json 声明的 GitHub 仓库，即可管理这个公开页面。认领后，Hub 会优先安排当前版本的安全扫描，并在通过后公开展示结果。
认领这个 Plugin →Trigger your CI and get it fixed — a dsh plugin bundle that runs GitHub Actions workflows and local test pipelines, streams their logs back, tracks their status, and when something fails hands the tail of the log to DeepSeek for a Markdown root-cause report with fix steps.
workflow_dispatch
(+ check-run APIs) and local command pipelines (npm test, pytest, …)
through the platform shell.ctx.llm (or any configured
OpenAI-compatible endpoint) to produce a report covering failure stage,
error classification, most likely root cause, suggested fix steps and
related files.queued / in_progress /
completed) with configurable interval and a hard timeout.fetch + node:child_process, plain
Node.js ESM, ships with five tools (ci_trigger, ci_status, ci_logs,
ci_watch, ci_diagnose) and a matching CLI.your repo / your machine
│ workflow_dispatch + check-run APIs shell (npm test, pytest, …)
▼ ▼
GitHubApi (fetch) LocalRunner (child_process)
│ │
└──────────────► CiService ◄────────────────┘
│ trigger · status · logs · watch · diagnose
├─► dsh adapter: five ci_* tools on ctx.tools (ctx.llm for analysis)
├─► CLI: ci-runner trigger|status|logs|watch|diagnose
└─► report: Markdown with the five canonical sections
All state (stored local runs, config, secret-masking) lives in one
CiService instance, so tools and CLI behave identically. The dsh adapter
and the CLI are two thin entry points over it.
fetch)tools service (and, for model-powered diagnosis, the llm service).GITHUB_TOKEN by default) with
actions:write scope for dispatch and actions:read for status/logs.A bundle is an npm package that contributes a configuration layer. From the profile you want to use:
dsh plugin --profile demo add ./path/to/ci-runner
This links the checkout and appends dsh-ci-runner to the profile's bundle
list because package.json declares dsh.bundle. Verify and boot:
dsh --profile demo --dump-config # shows the "# == dsh-ci-runner" layer
dsh --profile demo
The contributed patch layer (cordis.patch.yml) inserts one plugin row
mounting the adapter entry (a package subpath resolved through the package's
exports map):
- insert:
- id: ci-runner
name: dsh-ci-runner/adapter
Point the plugin row directly at the adapter source. Create an overlay file
ci-runner-patch.yml:
- insert:
- id: ci-runner
name: '<abs-path>/src/adapter.js'
and pass it to the harness:
dsh --patch ./ci-runner-patch.yml
When installed as a bundle, plugin configuration is set through the profile config (the layer contributed by the bundle) — every field is optional and defaulted:
# profile/config.yml
ci-runner:
github:
defaultRepo: acme/app
defaultBranch: main
diagnosis:
llm:
baseUrl: https://api.deepseek.com/v1
apiKey: sk-...
model: deepseek-chat
Without diagnosis.llm, analysis routes through the harness ctx.llm
service (preferred — matches the harness's configured provider). If neither
exists, diagnosis still produces a deterministic report (stage +
classification + log tail) with a note about the missing model.
| Field | Default | Meaning |
|---|---|---|
github.tokenEnv | GITHUB_TOKEN | Env var holding the GitHub token (read at call time, never logged) |
github.defaultRepo | '' | Default owner/repo for GitHub calls |
github.defaultBranch | main | Ref used when a trigger doesn't specify one |
github.apiBase | https://api.github.com | REST base (GitHub Enterprise override) |
github.pollIntervalMs | 5000 | Poll interval for status tracking |
github.pollTimeoutMs | 600000 | Hard cap for waiting on a run |
github.dispatchWindowMs | 20000 | How long a dispatch may take to surface a run id |
github.requestTimeoutMs | 30000 | Per-request HTTP timeout |
github.readLogChars | 30000 | Default tail cap for ci_logs |
local.cwd | . | Working directory for command runs |
local.timeoutMs | 120000 | Hard timeout per command |
local.maxOutputChars | 40000 | Per-stream output cap |
local.templates | [{name: 'npm test', command: 'npm test'}, {name: 'pytest', command: 'pytest'}] | Named command templates |
diagnosis.llm | null | OpenAI-compatible endpoint override {baseUrl, apiKey, model} |
diagnosis.provider | '' | ctx.llm provider route ('' = auto) |
diagnosis.model | '' | model ( = auto) |
Templates let the model and the CLI reference pipelines by name
(ci_trigger {source: local, command: 'npm test'}). Any value that doesn't
match a template name is treated as a raw shell command line.
| Tool | Purpose |
|---|---|
ci_trigger | Dispatch a GitHub workflow_dispatch (returns the run id) or run a local pipeline to completion |
ci_status | Single poll: status, conclusion, failed stage, jobs and steps |
ci_logs | Read logs, masked and tail-truncated; job selects one job |
ci_watch | (Optionally trigger and) wait until a run finishes; failed runs include the log tail |
ci_diagnose | End-to-end: run/wait, then send the failure tail to the analysis provider and return the Markdown report |
ci_diagnose (and the CLI diagnose command) always emit the canonical
sections:
# CI Failure Report
## Failure Stage ← first failing job/step (or "Unknown")
## Error Classification ← heuristic rule-based pre-analysis
## Most Likely Root Cause ← model analysis (or a note when no model is available)
## Suggested Fix Steps ← model analysis
## Related Files ← model analysis (or "None identifiable from the log")
## Timeline ← start/end/duration when known
## Failure Log Tail ← masked, tail-truncated
When a model is available, its free-form Markdown is parsed back into these sections before rendering, so the structure is stable even as the model's wording varies.
ci-runner trigger [--source github|local] [--repo owner/repo] [--workflow F]
[--ref R] [--inputs k=v ...] [--command CMD] [--template T]
[--cwd DIR]
ci-runner status [--source s] --run ID [--repo r]
ci-runner logs [--source s] --run ID [--job J] [--tail N] [--repo r]
ci-runner watch [--source s] [--run ID | trigger flags] [--timeout-ms N]
[--interval-ms N] [--no-logs] [--json]
ci-runner diagnose [--source s] [--run ID | trigger flags] [--save PATH]
[--llm-base-url URL] [--llm-model M] [--llm-api-key K]
Global: --config PATH (JSON config file), --json, --help, --version.
For diagnose without a config file, pass --llm-base-url (+ --llm-model
and optionally --llm-api-key; keys can also come from CI_RUNNER_LLM_API_KEY
or OPENAI_API_KEY).
Local run ids are process-local:
status/logson a local run work with a run id captured inside the same invocation. Across CLI invocations, drive local pipelines withwatch/diagnose+--command(or use GitHub runs, whose state lives server-side). Inside dsh, all five tools share one process, so captured run ids stay valid for the plugin's lifetime.
# GitHub: dispatch ci.yml on main with inputs and print the run id
ci-runner trigger --workflow ci.yml --repo acme/app --ref main --inputs env=prod
# Local: run the "pytest" template (or any raw command)
ci-runner trigger --source local --template pytest --cwd ./api
# Wait for run 123456789, show the tail if it failed
ci-runner watch --run 123456789 --repo acme/app --timeout-ms 600000
# Local failure → DeepSeek diagnosis (markdown report, also saved to disk)
ci-runner diagnose --source local --command "npm test" \
--llm-base-url https://api.deepseek.com/v1 --llm-model deepseek-chat \
--save report.md
process.env[github.tokenEnv] on every call
and exists only in memory; it is never written to logs, reports or disk.*** substitution).cwd only and are killed as a process
tree on timeout — no orphaned grandchildren keep running.bin/ci-runner.mjs CLI launcher
cordis.patch.yml bundle patch layer (mounts the adapter row)
src/
adapter.js Cordis plugin entry: name / inject / Config / apply
index.js public package surface (harness-free)
config.js canonical config, defaults, validation
github.js GitHub REST client (dispatch, runs, jobs, logs, checks)
local.js child_process runner (timeout, tree-kill, capped capture)
logs.js bounded buffers, tailing, ANSI cleanup, secret masking
classify.js rule-based failure classification
llm.js prompt building + OpenAI-compatible client (harness-free)
dsh-llm.js ctx.llm stream adapter (harness-side)
diagnose.js run metadata + Markdown report assembly
service.js cross-source orchestration (tools and CLI share it)
tools.js the five ci_* tool definitions
cli.js CLI implementation
test/ node:test suites (mock GitHub API, temp scripts, diagnosis flow)
examples/ config + profile overlay examples
npm install # peer deps (schemastery, dsh-llm) for the adapter tests
npm test # node --test
MIT
ctx.llm''diagnosis.maxTailChars | 12000 | Chars of the log tail sent to the model |
diagnosis.timeoutMs | 120000 | Hard budget for the analysis call |
diagnosis.temperature | 0.2 | Sampling temperature |
diagnosis.providerLabel | OpenAI-compatible | Label recorded in reports when the endpoint override is used |