Which config options should be shared with runners?

[willianrampazzo]

With #4303, configs starting with runner. are shared with runnables.

I envision more and more runnables added to the Avocado project and, maybe, some of them may need more information available in the test config.

An example is #4600. The runner needs access to datadir.paths.cache_dirs, but I don't think that should be a runner option, like runner.datadir.paths.cache_dirs.

Questions for discussion:

• Should we limit which configuration options are shared with the runnables?
• If a limited number of configuration options should be shared with runnables, how should we do that? Renaming the option to runner.something? Duplicatiing the information on runner.something?

Suggestions are welcome!

[beraldoleal]

Hi @willianrampazzo, I don't see a resaon right now to not send the entire config dict. I guess that the only reason for sending only runner.* is that we have already some configs starting with "runner."

So, unless I'm missing something, I cannot remember or think of any good reason for not sending the entire dict.

[marioaag]

As user I have been working with the runnable, suite and job manual generation and I found that could be useful to have all the config options available at the runnable level, in that way if is needed the options could be filtered or extra options could be aded for custom purpose.