General recommendations:
- log plugin activity by creating and using
app.lib.logger - set nci minor version with which plugin was tested as peer dependency, e.g. 0.9.x
- minimize dependencies, try to use dependencies used by core for similar kind of job (twostep for async flow control, underscore as functional programming helpers, conform.js for validation)
- write unit-tests for plugin (currently not all plugins listed as examples below have tests, sorry, that could happen)
Plugin depending on functionality could belongs to types following below.
Adds ability to load server and project configs of other (then json) formats.
To implement such plugin you need to make subclass of BaseReaderLoader.
See yaml reader plugin
for example.
Extends nci with different transports (e.g. mail, xmpp, etc) for notification
system on build error, status change, or successful completion (done).
To implement such plugin you need to make subclass of BaseNotifierTransport.
See mail notification plugin
for example.
Extends nci with different node types (e.g. ssh, docker, etc) for executing
builds. To implement such plugin you need to make subclass of BaseNode.
See ssh node plugin for example.
Can use following public api:
Could be used to append custom http request listener.
Examples: static server plugin, rest api server plugin
Could be used for manipulating with projects.
Only methods described in projects collection should be used.
Examples: scheduler plugin, projects reloader plugin, classic ui plugin
Could be used for manipulating with project builds.
Only methods described in builds collection should be used.
Examples: rest api server plugin, classic ui plugin