About Plugins¶
Plugins are individual blocks that power your orchestrator. You can create your own plugins or use and customize plugins shared by the OpenTestFactory community.
About Plugins¶
You can create plugins by writing custom code that interacts with your workflow in any way you would like, including integrating with any available third-party API. For example, a function can send SMS alerts when urgent issues are created.
You can write your own plugins to use in your workflow or share the plugins you build with the OpenTestFactory community.
Plugins can run directly on a machine or in a Docker container. You can define a plugin’s inputs, outputs, and environment variables.
Type of Plugins¶
The most common type of plugin is a plugin that consumes events from the event bus. The event bus is a message broker that allows different services to communicate with each other.
In response to this event, the plugin performs a specific action, and may emit events to the event bus to communicate with other services.
For example, a provider plugin subscribes to ProviderCommands
events, and then emits a
ProviderResult
event to communicate the result of the command.
Most plugins and services in the OpenTestFactory orchestrator are of this kind: they consume events from the event bus, and emit events to the event bus in response.
Some plugins simply consumes events from the event bus. One such plugin is the Tracker Publisher
plugin. It consumes WorkflowCompleted
events and convey the information it gathered from
this event to external services (GitLab or Jira instances, for example).
Some other plugins simply emit events to the event bus. One such plugin is the Receptionist
service: it emits Workflow
events, and consumes no events.
Finally, some plugins may simply interact directly with other services through their public endpoints. One such plugin is the Quality Gate service: it exposes a public endpoint that accepts requests, and then interacts with the Observer service. It neither publishes nor consumes events from the event bus.
Cartography¶
Writing Plugins¶
You can build plugins using any technology you like. Plugins require a metadata file to
define the inputs, outputs and main entrypoint for your plugin. The metadata filename must
be plugin.yaml
. For more information, see
“Descriptor Syntax.”
Creating a README File for your Plugin¶
We recommend creating a README file to help people learn how to use your plugin. You can include
this information in your README.md
:
- A detailed description of what the plugin does
- Required input and output arguments
- Optional input and output arguments
- Environment variables the plugin uses
- An example of how to use your plugin in a workflow