developing-plugins

Developing plugins

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.

Config reader

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.

Notifier transport plugin

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.

Node plugin

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.

Custom plugin

Can use following public api:

app.httpServer

Could be used to append custom http request listener.

Examples: static server plugin, rest api server plugin

app.projects

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

app.builds

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