PluginOverview

Plugins

RoboClerk is able to pull in information from a wide variety of different information sources. To support different information sources, RoboClerk uses a general plugin interface. This interfaces is easy to use and this makes RoboClerk easily expandable. Below we will first discuss the standard plugin interface of RoboClerk and then we'll take a look at what it would take to create your own plugin(s).

Plugin Interface

The plugin interface is defined in IPlugin which is documented here. This interface is partially implemented in an abstract class PluginBase. All plugins that come with RoboClerk derive from this abstract class. By default each plugin supports returning all types of items RoboClerk can handle. If a plugin only collects certain types of information (certain types of items) it will simply return an empty list for everything else. SLMS and Source Code Analysis plugins share certain functionality that is captured in an additional layer of abstract classes (i.e. SLMSPluginBase and SourceCodeAnalysisPluginBase).

The Standard Plugins

The following plugins come with RoboClerk:

• AzureDevOpsSLMSPlugin - interfaces with the AzureDevOps SLMS
• RedmineSLMSPlugin - interfaces with the Redmine SLMS
• AnnotatedUnitTestsPlugin - plugin that extracts unit test descriptions from annotations of the unit test functions. This is probably the best way to document your unit tests. Many of the unit tests in the RoboClerk project use this approach.
• UnitTestFNPlugin - plugin that extracts unit test descriptions from the test function name (requires that the function names have a standard format). Many of the unit tests in the RoboClerk project use this approach.
• DependenciesFilePlugin - plugin that extracts the dependencies from a dependencies file. It is usually up to the build pipeline to generate the dependencies file. Currently it supports Gradle and NuGet files. RoboClerk can compare this list of dependencies with the SOUP tickets it has found in the SLMS.

Building Your own Plugin

Building your own plugins is relatively simple. All that is needed is for the plugin to implement the IPlugin interface. However, an abstract plugin base class exists that contains some plumbing that you would likely need to create yourself. So, in practice, deriving from that baseclass, Pluginbase is the most convenient option. All you need to do is build your plugin as a dll and copy it and its dependencies into the plugins directory configured in RoboClerk.toml. Then, make sure the name of the plugin is included in the list of plugins that will be loaded, also configured in RoboClerk.toml. When RoboClerk loads your plugin it will call the Initialize function and pass a configuration object that contains all the project configuration information. Plugins are responsible for loading their own configuration file (if they need one). To get an idea of how to do that, take a look at one of the existing plugins. Plugins are typically packaged with the main RoboClerk executables in the Docker container while the configuration files are project specific. When RoboClerk is creating the documentation, it will call the RefreshItems function to get the latest items. Make sure that your plugin can handle multiple calls to this function.