Open mpalmer opened 4 years ago
I agree that the alternate runs backend should not be defined before all of Runbook is loaded. Breaking out all require statements to be present in all files where they are needed seems like it would incur quite a bit of overhead as opposed to simply including each file once, up front.
The extensions are implemented the way they are as a proof of concept for how Runbook can be extended with plugins. One solution could be to simply require the shared_variables
extension before runbook/run.rb
, drop the Runbook.runs
logic in the extension and invoke ::Runbook::Extensions::SharedVariables::RunHooks.register_shared_variables_hooks
within the Runbook::Run.included method.
I think the broader pattern that is missing is a place to invoke initialization logic, after any plugins or extensions have been loaded, but before the runbook is loaded/evaluated.
For individual projects, this is the Configuration.load_config method that is invoked before any Runbook logic, however there isn't any explicit pattern for initialization code that could be used for Runbook or other plugins. Long term, this is probably the missing pattern that needs to be implemented.
The way that variable sharing is implemented, using a set of hooks on the module, means that alternate runs backends don't get variable sharing without manually registering the hooks themselves.
It doesn't appear to be practical to define the alternate runs backend (in order to be present in
Runbook.runs
) before the extensions are loaded, because defining a runs backend requires includingRunbook::Run
. If all the files inrunbook
required their own dependencies, it would be possible torequire "runbook/run"
, but as all the files in the gem are loaded inlib/runbook.rb
, I suspect I would need to replicate two-thirds of that file in order to getRunbook::Run
to exist so I could include it.