Being able to access execution configs would definitely be useful. For reasons explained below, it is somewhat big task to implement and unfortunately not likely to happen in the near future.

A workaround is specifying important configs using variables like --include foo --variable include:foo. That's not too convenient if you use the standard robot command, but if you have a custom start-up script it can accept options itself and then call robot accordingly.

Reasons why this is rather big task to implement:

1. Current system for processing command line options is pretty old and bad. Most importantly, there isn't a good context object having all configs in one place, but there should be also new features like support for config files. I don't want to use the current (and bad) RobotSettings class in any public API because it will be changed sooner or later. Rewriting the whole config system isn't an absolutely mandatory precondition for this issue, but at least we should define the API of the object containing configs.

2. Listeners could potentially get a new initialize method like Add initialize listener method #722 proposed or a separate config method, but same approach wouldn't work with model modifiers, libraries, or in the test data. One simple possibility would be adding a new built-in variable like ${CONFIG} (or possibly &{CONFIG} as a dict) that could be directly used in test data and programmatically accessed via BuiltIn.get_variable_value(). It probably wouldn't work with model modifiers, though, so a separate public API somewhere in robot.api might be needed anyway. Designing and implementing all this is some work. Variable containing configs would probably also need its own issue.

3. Robot's internal execution context handling is not very good. Most importantly, you cannot execute tests in different threads because the framework isn't thread safe. We've been slowly enhancing this situation and hopefully can introduce proper context handling sometime in the future. We definitely don't want to make this situation worse, so this needs to be taken into account if we decide to add something execution configs related under robot.api.

Everything above is doable but there's just quite a lot to do and also to design. I won't have time to do that myself in the near future, but can help if someone else is interested.

Hi Pekka,

Using a BuiltIn Variable would absolutely solve my issue because i need to access it as Library Listener. So i have access to These.

As you wrote, i already decided to implement a workaround with ${exclude} variables. But user friendly is different.

Cheers.

Hi @pekkaklarck, @Snooz82 ,
I know the feature is probably not required anymore by @Snooz82 . But despite that, i would also like to see this feature. My use-case is to access the include and exclude tags to dynamicaly run tests differently based on these tags (e.g. running test in different environments). Using variables is possible, but if one could access the tags this could be done more efficiently.

Could you consider my PR?

Thanks!

As I just commented the PR (very late, sorry), I think it would be better to expose configuration options via a single variable &{SETTINGS} that could then be accessed like ${SETTINGS}[exclude]. Adding separate variable for each option would kind of pollute the variable namespace. The first step towards that direction would be submitting a new issue about that. Implementation wouldn't be any more complicated than what's already done in the PR so there would be good time to get it into RF 5.0 still.

This has been implemented by #4229 as &{OPTIONS}.