feat: support for complex hook plugin configuration #164
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds support for complex hook plugin configuration as requested in #163.
implementation
As this change is a little more advanced I'll describe the important details below.
changes to config structure
In order to support complex hook plugin configuration the config structure had to be changed a little:
plugins.hooks.<plugin>@<version>
now supports any json value/structure and nestingchanges to hook plugin
Init
functionHook.Init
function was removed from the interface and is checked at runtime through reflection to support variable argumentshooks.Server.Init
callback validates theHook.Init
function of the plugin and parse theplugins.hooks.<plugin>@<version>
json to the type of the first argument ofHookImpl.Init
HookImpl.Init
must befunc (*<HookImpl>) Init(<any structure>) error
orhooks.Server.Init
will throw an errorHookImpl.Init
function acceptsmap[string]string
, thus no changes to existing plugin code is required (plugin must be compiled with newer semantic-release tho; see drawbacks for details)drawbacks
This solution comes with some drawbacks I couldn't solve right now:
Init
function was removed from theHooks
interface, thus compiling plugins without or with invalidInit
function will succeedInit
needs to accept different typesInit(interface{})
and let the plugin author handle the conversion/decoding of the options to its appropriate typeHook
interface will stop work due to changes to thehooks.Server
function. They won't produce errors but silently do nothing. Thus, every plugin has to be compiled against this change.to do
As this is a draft and I'm unsure if it gets picked up at the moment, there are a few things I will implement after a positive response:
Init(interface{})
if the missing interface function is a huge problem/no-go