SuperAPI AI Directory
Partner with us中文AI newsFavorites
All toolsAI codingActionD

ActionD

Local CI/CD for agents: runs jobs on LGH git events in isolated checkouts, with failure diagnosis, approval gates, auto-rollback and a web console.

Open website

About this tool

Purpose

ActionD is a lightweight local CI/CD engine for AI agents. It listens for Git events from LGH (Local Git Hub) and automatically triggers plugins to perform tasks such as code checks, tests, and builds.

Main Capabilities

  • Dynamic plugin discovery: Plugins are automatically discovered via manifest.json, with no code changes required.
  • MCP integration: A built-in MCP server lets AI assistants directly query and control CI/CD.
  • Event-driven: Responds to LGH events such as git.push and git.tag.
  • Web console: Provides a real-time monitoring dashboard, with the default address http://localhost:3000。
  • Real-time streaming output: Outputs real-time logs via SSE (Server-Sent Events).
  • Hot reload: Reload plugins without restarting.
  • End-to-end workflow: dev_cycle_run completes commit → CI → result in a single call.
  • Rollback: Automatically rolls back to the previous commit on failure.
  • Failure diagnosis: Built-in failure pattern recognition analyzes common errors and provides fix suggestions (implemented on the Go side, located at internal/interpreter/failure.go).
  • Approval gate: Blocked tasks can be approved via CLI actiond approve <job_id> or REST POST /api/actions/{id}/approve .
  • Structured result protocol: Plugins can return a standard ActionResult structure for use by downstream decision gates (for example, the Policy Gate plugin reads signals produced by other plugins).
  • Layered logs: Provides logs in different formats for different audiences, including an AI summary format.

Core Concepts

  • Job: A CI/CD execution record produced when a plugin responds to a Git event. Some tool names (actiond_action_get, actiond_actions_list) retain the legacy term action and refer to the same object as the actiond_job_* tools.
  • Plugin: An executable unit registered via manifest.json and run on trigger events (git.push, git.tag); one plugin run produces one Job.
  • Profile: A CI scope preset (fast / full / release) that controls which plugins run on each push.

Installation and Usage

Environment Requirements

  • macOS / Linux (Homebrew)
  • LGH running locally (installation method:brew install JoeGlenn1213/tap/lgh)
  • Go 1.25+ (required only when building from source)
  • Python 3.8+ (used by plugins)

The built-in plugin package (30+ check plugins) is embedded in the binary.actiond setup It will extract them to ~/.localgithub/plugins, so Homebrew or release package installations run the same checks as a source checkout, with no additional resource downloads required. The Web console is optional: it can still run without installing the console API (see actiond-web or pass --web-dir).

Building from Source

ActionD uses SQLite storage (the pure Go modernc.org/sqlite build), requires no CGO,make build and can be freely cross-compiled.make release Defaults to the current host platform, can be overridden via RELEASE_PLATFORMS="linux/amd64 linux/arm64 darwin/arm64".

One-Click Setup (Recommended)

On first run, use setup to install the built-in plugin package, check dependencies, create the directory structure, and verify the environment: (see the original text for the command content) Re-running setup is safe: installed plugins and local modifications will not be overwritten (use --force to reset to the bundled version, --skip-plugins to skip installation entirely). After setup is complete, you can also start the daemon in the background.

Start the Service and Check

(see the original text for the command content)

Open the Web Console

Default directories and auto-detection:

  • Plugin directories are probed in order: <binary directory>/plugins → <working directory>/plugins → ~/.localgithub/plugins
  • Web static assets are auto-detected in common locations; the recommended target is to publish ActionD-Web's out/ to ~/.localgithub/actiond-web/out
  • When --repo-root is not explicitly specified, ActionD first resolves the repository via the LGH mapping, then falls back to current-directory semantics.

One-Click Setup (v1.2+)

Automatically completes: creating the directory layout (~/.localgithub/*), checking dependencies (Git, Python, Go, Node), detecting Web assets and plugin directories, verifying the LGH connection, and running 8 categories of tiered checks (system environment, dependencies, service status, ports, directories, storage, plugins). Results are divided into three levels: FATAL (the system cannot work), WARN (some functionality is affected), INFO (information only). If doctor reports that the Go plugin is disabled, it can be restored directly.

Dynamic Plugin Discovery (V1.0.7+)

Add new plugins with zero code: just create manifest.json in the plugin directory. Plugin directory scan order: system plugins ./plugins/ (next to the binary), development plugins ./plugins/ (current working directory), user plugins ~/.localgithub/plugins/.

Structured Result Protocol — ActionResult (v1.2+)

Plugins can print JSON to stdout, and ActionD automatically parsesand stores it; it can also be written to $ARTIFACT_DIR/result.json.

Failure Interpreter (v1.2+)

Built-in failure pattern recognition, automatically analyzes common errors and suggests fixes. Recommended interface on the AI side: MCP tool actiond_diagnose(job_id=...), return root cause and fix suggestions; the HTTP side uses a REST API.

MCP Server Integration

ActionD has a built-in MCP (Model Context Protocol) server, allowing AI assistants (such as Claude) to directly query and control CI/CD. Starting the MCP server lets AI start/stop/restart ActionD itself via MCP (environment variables must be set before startup). Available resources: actiond://status, actiond://plugins, actiond://actions. ActionD uses MCP over standard stdio, and any MCP-compatible client can use it (Claude Desktop/Code, Cursor, ZCode, Windsurf, etc.).

dev_cycle_run End-to-End Workflow (V1.0.8+)

dev_cycle_run is an aggregate tool that completes a full development cycle in a single MCP call. Verification is tri-state, and success is true only when it is pass (same vocabulary and aggregation rules as actiond_run_report):

  • pass — at least one Job ran and all passed
  • fail — at least one Job failure was observed
  • unknown — zero Jobs, CI query error, or timeout; never counted as pass Jobs are associated with this run via LGH event ID, or (fallback) via exact repository name plus commit sha; green Jobs from old commits or similarly named repositories are never accepted as verification of the current change.

Configuration and Logs

  • Runtime configuration file: ~/.localgithub/actions/config.json
  • Plugins can be disabled, triggers overridden, and custom plugins added via configuration (no manifest.json required)
  • Layered logging (v1.2+) provides different formats for different audiences, including an AI summary format

Use Cases

  • AI agent-driven CI/CD in local development environments
  • Need for AI assistants to directly query and control CI/CD processes
  • Continuous integration requiring automatic rollback, approval gates, and failure diagnosis
  • Quickly adding custom check plugins without modifying engine code

Limitations and Notes

  • Requires LGH to be running locally
  • Web consoleis an optional component
  • Building from source requires Go 1.25+; running plugins requires Python 3.8+
  • There is no MCP tool for approving blocked Jobs; use the CLI actiond approve <job_id> or REST POST /api/actions/{id}/approve
  • Failure analysis is implemented on the Go side (internal/interpreter/failure.go); there is no actiond Python package
  • License: MIT (see LICENSE)
  • Related projects: LGH (Local Git Hub), actiond-web (Web console UI)

Related tools

Browse category