简体中文

ci-runner

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.

• Two sources, one interface: GitHub Actions via workflow_dispatch
  (+ check-run APIs) and local command pipelines (npm test, pytest, …)
  through the platform shell.
• Bounded log reading: GitHub job logs streamed back per job and
  tail-truncated; local output captured with a per-stream cap so a runaway
  process can't blow up the agent context.
• DeepSeek diagnosis: on failure, the tail log plus a heuristic error
  classification is sent to the harness 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.
• Status tracking: poll runs to completion (queued / in_progress /
  completed) with configurable interval and a hard timeout.
• Credentials by environment only: the GitHub token is read from an
  environment variable at call time, never logged and never persisted; every
  returned log and report is masked against known secrets.
• Zero runtime dependencies: 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.

How it works

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.

Requirements

• Node.js >= 18.17 (global fetch)
• For the dsh integration: a working DeepSeek Harness install providing the
  tools service (and, for model-powered diagnosis, the llm service).
• A GitHub token in the environment (GITHUB_TOKEN by default) with
  actions:write scope for dispatch and actions:read for status/logs.

Installation into dsh

As a dsh bundle (recommended)

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

As a patch overlay (no packaging)

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

Applying plugin config

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.

Configuration

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.

Tools

Report structure

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.

CLI

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/logs on a local run work with a
run id captured inside the same invocation. Across CLI invocations, drive
local pipelines with watch/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.

Examples

# 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

Security notes

• The GitHub token is read from process.env[github.tokenEnv] on every call
  and exists only in memory; it is never written to logs, reports or disk.
• All returned log text is masked against the GitHub token and any configured
  analysis API key (*** substitution).
• Local commands run in the configured cwd only and are killed as a process
  tree on timeout — no orphaned grandchildren keep running.
• Diagnosis payloads contain the log tail only; the token never reaches the
  model.

Project layout

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

Test

npm install   # peer deps (schemastery, dsh-llm) for the adapter tests
npm test      # node --test

License

MIT