Starter Plugin Example
Clone​
Clone the Hoppr Starter Plugin as a basis for your first Hoppr plugin:
[~]$ git clone https://gitlab.com/hoppr/plugins/starter-plugin.git
Try a Bundle​
Assuming you have already installed Hoppr, execute a bundle
from your starter plugin directory:
[starter-plugin]$ hopctl bundle starter_files/manifest.yml --transfer starter_files/transfer.yml --credentials starter_files/credentials.yml
How it Works​
This starter plugin logs output to show the Hoppr processing flow using a complete set of core input files (Manifest, SBOMs, Transfer, Credentials). Make sure to read through the comments and NOTE:
sections in the Starter Plugin's plugin.py
to get a better feel for how a plugin operates!
Building off Starter Plugin​
We strongly recommend that any plugin class inherit from the HopprPlugin
class (in the hoppr.base_plugins.hoppr
module), which provides the framework for:
- The
__init__
constructor, which takes two arguments:- The Hoppr
context
, which includes information about the current state of the process, - (Optional) the
config
to be used (as a Pythondict
object). Since the configuration is specific to each plugin, there are no requirements for its structure. The starter plugin demonstrates use ofconfig
inside thepre_stage_process
method.
- The Hoppr
- Reporting the version number as a string via the
get_version()
method. This is implemented as an abstract method in theHopprPlugin
base class, and must be overridden. - Methods to handle SBOM processing. Each should return a
Result
object (defined inhoppr.result
). When sub-classingHopprPlugin
, each by default returns aResult
object with the status ofSKIP
, meaning that the process did nothing, and the logs for that process will be deleted. Read more about plugin layout in the overview.