Before this PR, MultiHTTP and ScriptedProbers created k6 runners using only the raw script data ([]byte) as input to the runner. This have worked nicely, as until now runners only required two things to work: The raw script data, and a timeout that was encoded in the context for Runner.Run().
We have seen however a couple scenarios that make me think this is not enough for the near future:
We want to decouple the context from Runner.Run(), a.k.a. the request timeout, from the check timeout that is communicated to the runners. This is needed to properly implement what #715 workarounded.
For these three reasons, I think it is beneficial to create a richer type so that Probers can feed all these details to the k6 runner, which this PR does.
Please note that this PR is not feature complete, namely how timeouts are handled does not fully makes sense. This is because I tried to keep the patchset as small as possible for reviewability. How timeouts are handled is improved in #724.
Before this PR,
MultiHTTPandScriptedProbers created k6 runners using only the raw script data ([]byte) as input to the runner. This have worked nicely, as until now runners only required two things to work: The raw script data, and a timeout that was encoded in the context forRunner.Run().We have seen however a couple scenarios that make me think this is not enough for the near future:
Runner.Run(), a.k.a. the request timeout, from the check timeout that is communicated to the runners. This is needed to properly implement what #715 workarounded.For these three reasons, I think it is beneficial to create a richer type so that
Probers can feed all these details to the k6 runner, which this PR does.Please note that this PR is not feature complete, namely how timeouts are handled does not fully makes sense. This is because I tried to keep the patchset as small as possible for reviewability. How timeouts are handled is improved in #724.