Example

In this example, one plugin called “myplugin” will be run twice with different configs. The output is sent to stdout. The plugin takes two parameters, one of which is a list.

---
analysis:
  - plugin_name: myplugin
    name: Check config 1
    myplugin_param_1: config val
    myplugin_param_2:
      - list item 1
      - list item 2
  - plugin_name: myplugin
    name: Check config 2
    myplugin_param_1: some other val
    myplugin_param_2:
      - list item 7
output:
  - plugin_name: stdout

The “myplugin” entry point (see below) will be passed a dictionary containing (note that the “plugin_name” parameter is stripped out):

{
"name": "Check config 1"
"myplugin_param_1": "config val",
"myplugin_param_2": ["list item 1", "list item 2"]
}

And then it will be executed again with

{
"name": "Check config 2"
"myplugin_param_1": "some other val",
"myplugin_param_2": ["list item 7"]
}

It is also possible to include plugin configurations. For example, in the main config file:

---
analysis:
  - include: myplugin_config.yml

The contents of myplugin_config.yml are:

---
- plugin_name: myplugin
  name: Check config 1
  myplugin_param_1: config val
  myplugin_param_2:
    - list item 1
    - list item 2

Note that the included file only has a list of plugins, not the “analysis” tag. It is possible to recursively include files in included files as well as to have plugin configurations and include statements in the same file.

Example:

setup(
...
entry_points={"pordego.analysis": ["myplugin = mypackage.mymodule:some_function"]},
...
)

The function receives a dictionary containing the configuration for the plugin as specified in the file passed to pordego

Returning Errors and Succeess

For simplicty’s sake, the interaction between the pordego tool and the plugins is minimal. There are three states that a plugin can comminucate depending on what exceptions are raised.

• Don’t raise an exception- pordego assumes that the plugin has passed

• raise AssertionError- pordego assumes that the condition that the plugin is checking (e.g. code complexity) has failed. Pordego prints out the exception but not a stack trace.

• raise any other exception- pordego assumes that the plugin or configuration is in error so it prints out a stack trace to aid in debugging