You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, test step plugins are required to have the following interface:
Load() (
string, // plugin identifiertest.TestStepFactory, // instance factory: func() test.TestStep
[]event.name// events allowed to be emitted
)
Run(
ctxxcontext.Context, // cancellation contextchtest.TestStepChannels, // input, output chansevtestevent.Emitter, // event emitter interfacestepsVarstest.StepsVariables, // step output variables accessorparamstest.TestStepParameters, // map[string] -> list of Param (raw json)resumeStatejson.RawMessage, // input serialized plugin state, when resuming
) (
json.RawMessage, // output serialized plugin state, when pausingerror
)
ValidateParameters(
ctxxcontext.Context,
paramstest.TestStepParameters// map[string] -> list of Param (raw json)
) error// required but unusedName() string
Most also define (but not required by contest server):
New() test.TestStep// passed in test.TestStepFactory in Load()
The lifecycle of a plugin is: instance is created before main loop and put into a "step bundle" object (owned by test, and then job), that gets carried around until it reaches StepRunner (field of StepState, should also be removed). Step runner calls Run() once (per job, new TestRunner made in JobRunner), and leaves it running in a goroutine. Step runner is stopped in stepState.DecreaseLeftTargets, when number of targets remaining to be injected into a step plugin is 0 (note, this whole thing needs refactoring, but that's for another tracking issue).
Issue 1: The validate params method is usually implemented by another method in plugins, that also gets called at the beginning of Run(), resulting in a double parsing of the input json.
Instead, the plugin instance should be valid by construction. This implies removal of the ValidateParameters method, and plugin config structs should be created along with the plugin instance. Config param interpolation can be done in Run() on a per target basis.
Issue 2: The Run method requires a number of dependencies from inside the server core, and this list may increase later (as was the case with StepsVariables). These dependencies may also depend on other objects, which will in effect explode the signature of Run.
Instead, an interface should be presented to the plugin (we dont require ABI compat) which contains getter methods for these dependencies (called services here).
Proposal
typePluginServicesinterface {
EventEmitter() testevent.EmitterStepsVariables() test.StepsVariablesLogger() xcontext.Logger// with any tags needed// maybe Metrics() xcontext.Metrics// maybe Tracer() xcontext.Tracer// maybe something to provide state pause/resume services// other
}
// note that xcontext.Context is also removed, for the standard golang ContextRun(
ctxcontext.Context,
chanstest.TestStepChannels,
paramstest.TestStepParameters,
svcPluginServices, // newresumeStatejson.RawMessage,
) (json.RawMessage, error)
Issue 3: The plugin currently accepts both a target input chan and an output one. It is generally advised that chans are created by the code that knows most about said channel. In this case, the input chan should be created by caller, but the output should be created by the plugin.
Proposal (provisional, may instead require Run to launch async itself and return an output chan)
Currently, test step plugins are required to have the following interface:
Most also define (but not required by contest server):
The lifecycle of a plugin is: instance is created before main loop and put into a "step bundle" object (owned by test, and then job), that gets carried around until it reaches StepRunner (field of StepState, should also be removed). Step runner calls Run() once (per job, new TestRunner made in JobRunner), and leaves it running in a goroutine. Step runner is stopped in stepState.DecreaseLeftTargets, when number of targets remaining to be injected into a step plugin is 0 (note, this whole thing needs refactoring, but that's for another tracking issue).
Issue 1: The validate params method is usually implemented by another method in plugins, that also gets called at the beginning of Run(), resulting in a double parsing of the input json.
Instead, the plugin instance should be valid by construction. This implies removal of the
ValidateParameters
method, and plugin config structs should be created along with the plugin instance. Config param interpolation can be done in Run() on a per target basis.Issue 2: The Run method requires a number of dependencies from inside the server core, and this list may increase later (as was the case with StepsVariables). These dependencies may also depend on other objects, which will in effect explode the signature of Run.
Instead, an interface should be presented to the plugin (we dont require ABI compat) which contains getter methods for these dependencies (called services here).
Proposal
Issue 3: The plugin currently accepts both a target input chan and an output one. It is generally advised that chans are created by the code that knows most about said channel. In this case, the input chan should be created by caller, but the output should be created by the plugin.
Proposal (provisional, may instead require Run to launch async itself and return an output chan)
The text was updated successfully, but these errors were encountered: