Plugin Overview

Windshift uses Extism and WebAssembly (WASM) for plugins. Plugins run in a sandbox and extend Windshift with custom functions.

How It Works

Build plugins as WASM modules. Windshift loads them when it starts. Each plugin runs in an isolated sandbox with configurable resource limits:

Setting Default
Execution timeout 5 seconds
Memory limit 64 MB

Plugins use host functions to communicate with Windshift. These APIs provide access to email, HTTP, storage, SCM, and other services.

Plugin Structure

A plugin contains:

  1. manifest.json: Metadata, entry point, and extension definitions.
  2. plugin.wasm: The compiled WASM binary.
  3. Static assets: Optional HTML, JavaScript, and CSS files for UI extensions.

Example manifest:

{
  "name": "my-plugin",
  "version": "1.0.0",
  "description": "A custom plugin for Windshift",
  "entryPoint": "plugin.wasm",
  "extensions": [
    {
      "point": "admin.tab",
      "id": "my-plugin-tab",
      "label": "My Plugin",
      "displayMode": "iframe",
      "component": "index.html",
      "group": "Tools"
    }
  ]
}

Extension Points

Plugins can register extensions at defined points in the Windshift UI:

Extension Point Description
admin.tab Adds a tab to the admin panel

Future releases will add more extension points.

Capabilities

Host functions let plugins:

  • Send HTTP requests: Call external APIs with configurable timeouts.
  • Send emails: Use SMTP to send notifications.
  • Store data: Use persistent key-value storage for each plugin.
  • Run CLI commands: Execute system commands.
  • Create comments: Add comments to work items.
  • Interact with SCM: Create branches and link items to repositories.
  • Log messages: Write to the Windshift server log.

See Plugin API for the full host function reference.

Disabling Plugins

To run Windshift without the plugin system:

./windshift --disable-plugins

Or via environment variable:

export DISABLE_PLUGINS=true

What's Next