Writing a plugin
A plugin is a shared library that bddkit loads at startup. It adds steps that testers write in feature files, and a resource group: a block under resources: in the config that the plugin reads, while bddkit itself never looks inside it. A browser, a phone app or an object store is reached this way.
A plugin runs inside the bddkit process with the same rights as bddkit: it can read files, use the network, read the environment and exit the process. bddkit checks that the plugin matches the version it expects, but those checks do not sandbox it. Installing a plugin is the same decision as installing any other program on the machine.
Starting one
Section titled “Starting one”Write a Rust crate that builds as a cdylib. The repository contains a complete, working example in tests/fixtures/echo-plugin, which is a good starting point to copy. Replace the steps it defines with your own.
For a plugin that drives a real system, read bddkit-s3. It handles the parts a small example leaves out: validating a configuration bddkit cannot check itself, telling a temporary failure from a permanent one, and keeping credentials out of failure output.
A plugin talks to bddkit through JSON. The example crate shows the functions bddkit calls and the JSON it expects back.
Publishing
Section titled “Publishing”Tag each release as v followed by the version, for example v0.1.0. Attach one archive per platform. Each archive holds exactly one dynamic library. Attach a .sha256 file beside each archive. Attach a bddkit-plugin.json file that names the plugin ABI version that bddkit must match. bddkit-exec publishes its releases this way and is a working template.
To make the plugin installable by name, open a pull request in bddkit/bddkit that adds one entry to plugin-registry.yaml. Its name must be the plugin’s own name.