Plugins

A Walis plugin does one thing: turn the parameters a user filled in into a shell snippet. Walis runs that snippet as one step of a build.

That constraint is the whole design. A plugin produces data, not behaviour — so before installing one you can press Preview and read exactly what it will run.

Why not the Jenkins model

Jenkins plugins can do anything: they run in the same JVM as the controller, with no sandbox. That is why the ecosystem is enormous, and also why one leaking plugin takes down the controller and why so many advisories start with a plugin name.

Walis cannot offer that power and still let you install something a stranger wrote. It picks the second thing.

What a plugin may reach

Only what the manifest declares:

"permissions": {
  "http": ["https://acme.atlassian.net"],
  "secrets": ["JIRA_TOKEN"]
}

Secrets are usable but not readable — the plugin asks the host to put a value into a header and never receives it. Without that rule, any plugin with network access could ship your token anywhere.

The runtime is Jint, a pure C# JavaScript interpreter: no require, no fs, no process, no npm at runtime. Limits are 10 s, 8 MB, 500,000 statements and recursion depth 64.

Installing is an admin action

A plugin is code that will be executed, so /api/plugins requires an admin role — an operator key cannot install one.

Next: writing a plugin.