Notifications¶
A plugin typically consumes events and may produce events on its own. It may also produce notifications, which are events that may be consumed by other services that only carry informational elements.
Format¶
Notification events are JSON documents with the following four entries:
apiVersion
: a string,opentestfactory.org/v1alpha1
.kind
: a string,Notification
.metadata
: an object with at least aname
entry. It may contain other entries.spec
: an object with any number of entries.
Normalized notifications¶
Some notifications are standardized. Your plugins may produce them, but they then should respect their semantics, as other services may consume them and have some associated expectations.
Workers¶
A plugin or service may declare an interest on a given workflow. To do so, it must
include a workflow_id
entry in the notification metadata, as well as a
spec.worker.worker_id
entry and a spec.worker.status
entry.
The worker_id
is generated by the plugin. It must be a string.
The expectation associated with this normalized notification is that the workflow_id
is
valid and that for a given worker_id
there will be a status: setup
notification and a
status: teardown
notification.
{
"apiVersion": "opentestfactory.org/v1alpha1",
"kind": "Notification",
"metadata": {
"name": "Report processor",
"workflow_id": "..."
},
"spec": {
"worker": {
"worker_id": "...",
"status": "setup"
}
}
}
Non-normalized notifications¶
A plugin (or a set of plugins) may decide to provide their own notifications. The
notification schema is extendable and plugins may add their own entries under the spec
section.
Those entry names must include a dot (.
) but may not start with opentestfactory.
or
org.opentestfactory
.
Here are some examples of valid and invalid entry names:
myentry invalid (does not contain a dot)
.myentry valid
com.example.notif valid
org.opentestfactory.notif invalid (starts with a reserved string)
The values associated with those non-normalized entries can be any valid JSON values.