The purpose of exporter units is to provide an easy way to customize the plainbox reports by delagating the customization bits to providers.
Each exporter unit expresses a binding between code (the entry point) and data. Data can be new options, different Jinja2 templates and/or new paths to load them.
Exporter entry units are regular plainbox units and are contained and shipped with plainbox providers. In other words, they are just the same as job and test plan units, for example.
Following fields may be used by an exporter unit.
id
:summary
:entry_point
:file_extension
:options
:(optional) - comma/space/semicolon separated list of options for this exporter entry point. Only the following options are currently supported.
Same as for text and additionally:
data
:This is an example exporter definition:
unit: exporter
id: my_html
_summary: Generate my own version of the HTML report
entry_point: jinja2
file_extension: html
options:
with-foo
with-bar
data: {
"template": "my_template.html",
"extra_paths": [
"/usr/share/javascript/lib1/",
"/usr/share/javascript/lib2/",
"/usr/share/javascript/lib3/"]
}
The provider shipping such unit can be as follow:
├── data
│ ├── my_template.css
│ └── my_template.html
├── units
├── my_test_plans.pxu
└── exporters.pxu
Note that exporters.pxu is not strictly needed to store the exporter units, but keeping them in a dedidated file is a good practice.
In order to call an exporter unit from provider foo, you just need to use in in the launcher.
Example of a launcher using custom exporter unit:
#!/usr/bin/env checkbox-cli
[launcher]
launcher_version = 1
[transport:local_file]
type = file
path = /tmp/submission.html
[exporter:my_html]
unit = 2013.com.foo.bar::my_html
[report:local_html]
transport = local_file
exporter = my_html
For more information about generating reports see Generating reports