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
configto be used (as a Pythondictobject). Since the configuration is specific to each plugin, there are no requirements for its structure. The starter plugin demonstrates use ofconfiginside thepre_stage_processmethod.
- The Hoppr
- Reporting the version number as a string via the
get_version()method. This is implemented as an abstract method in theHopprPluginbase class, and must be overridden. - Methods to handle SBOM processing. Each should return a
Resultobject (defined inhoppr.result). When sub-classingHopprPlugin, each by default returns aResultobject 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.
Existing Ecosystem Plugins​
To see a few of the current existing ecosystem plugins see below. Nexus Bundler Openssf Scorecard Hoppr-Cop