[ENHANCEMENT] vs code variables in settings and robot.toml

[otsoni]

Is your enhancement request related to a problem? Please describe.
Sometimes we need to configure things in a way that we can pint to things like ${workspaceFolder} and ${relativeFile} (https://code.visualstudio.com/docs/reference/variables-reference). At least I would need to have that working for robotcode.robot.paths so that it points to ${relativeFile} but it seems that it doesn't work in either of settings.json or robot.toml. At least the play button is missing next to tests after trying to configure that.

Describe the solution you'd like
I would like to be able to use vs code variables in settings.json or robot.toml. Preferrably both.

Describe alternatives you've considered
No alternative that I have found yet

Additional context
The base need for me is to get rid of suite naming syntax of Project.Folder.Folder.File.Test and get it just as File.Test. The same is explaned earlier here https://forum.robotframework.org/t/robotcode-whole-project-marked-as-test-suite/7301/7, but there is no resolution for the problem there.

[d-biehl]

Thanks for the issue.

I think the first thing to clarify is that this may not primarily be a VS Code variable substitution issue, but rather a test discovery / suite root configuration issue.

If the main goal is to avoid suite names like Project.Folder.Folder.File.Test and get something shorter like File.Test, then the most relevant setting is usually paths.

In RobotCode, paths defines where test discovery starts. Since Robot Framework derives suite names from the executed file / directory structure, using a lower-level discovery root can already reduce long suite names significantly.

For example, if your project looks like this:

my-project/
├─ robot.toml
├─ tests/
│  ├─ folder/
│  │  └─ file.robot

and your robot.toml contains:

paths = ["tests"]

then discovery starts from tests instead of from the full project root. If needed, you can make it even more specific:

paths = ["tests/folder"]

That may already solve the suite naming problem without requiring ${relativeFile} support.

If you do not want to use robot.toml, there is also the VS Code setting robotcode.robot.paths.

However, that setting is VS Code-specific. It works inside the editor, but it is not part of the shared RobotCode project configuration and therefore cannot be reused by the RobotCode CLI tools. So if you want one configuration that works both in VS Code and on the command line, robot.toml is usually the better option.

Another common case is that a repository contains two different logical projects:

• a main project with the actual application sources, for example in Go, Rust, Java, or a web stack
• and somewhere further down a separate Robot Framework project built around Python

In that kind of setup, treating the whole repository as one single Robot Framework root often does not make much sense, because both parts have different roots and different execution contexts.

In practice, this often works better with a multi-root VS Code workspace: open the main project, then add the Robot Framework project as a second folder in the same workspace. In that setup, it can also make sense to disable RobotCode for the main project folder, for example via robotcode.disableExtension, and keep it enabled only for the Robot Framework project.

Only after that comes the question of variable substitution.

robot.toml is not a native VS Code settings file, so VS Code variables like ${workspaceFolder} or ${relativeFile} are not expanded there automatically. And even in settings.json, variable substitution only works where VS Code itself applies it for that specific setting.

So supporting VS Code-style variables in robot.toml or in extension settings could still be a valid enhancement request, but I do not think that is necessarily the root cause of the suite naming problem described here.

Could you share:

• your exact robot.toml and/or settings.json configuration
• the relevant project structure
• the suite name you currently get
• and the suite name you expect instead

My guess is that this can probably already be solved either by setting paths correctly or by using a proper multi-root workspace setup, without requiring ${relativeFile} support.

Relevant documentation:

• robot.toml / configuration overview: https://robotcode.io/02_get_started/configuration
• configuration reference: https://robotcode.io/03_reference/config

[otsoni]

robot.toml is not a native VS Code settings file, so VS Code variables like ${workspaceFolder} or ${relativeFile} are not expanded there automatically. And even in settings.json, variable substitution only works where VS Code itself applies it for that specific setting.

So supporting VS Code-style variables in robot.toml or in extension settings could still be a valid enhancement request, but I do not think that is necessarily the root cause of the suite naming problem described here.

I read more about settings.json and it seems that it's not necessary to use variables in settings.json. I don't even know if it is really possible or not. And totally not something that robot.toml should support.

My project structure is following:

robotcode-test/
├─ .vscode
│  ├─ launch.json
│  └─ settings.json
├─ documentation/
│  └─ README.md
├─ lib/
│  ├─ MyRobot.py
│  └─ some_library.py
├─ robots/
│  ├─ MyRobot1/
│  │  └─ MyRobot1.robot
│  ├─ MyRobot2/
│  │  └─ MyRobot2.robot
├─ robot.toml
├─ pyproject.toml

.vscoe/settings.json is:

{
    "python-envs.defaultEnvManager": "ms-python.python:system"
}

robot.toml is:

[variables]
"CUSTOMER" = "customer1"

When running through Run and Debug tab using RobotCode: Run Current I get suite name MyRobot1 for MyRobot1.robot and ´MyRobot2for MyRobot2.robot and that is what I am expecting too. When running through the Run and Debug tab usingRobotCode: Run AllI get suite namesRobotcode-Test.Robots.MyRobot1.MyRobot1andRobotcode-Test.Robots.MyRobot2.MyRobot2. That could be ´MyRobot1 and MyRobot2, but for me it doesn't really matter as I am never running all suites at once.

When running through ctrl-shift-p -> RobotCode: Run Current File, Iget suite names Robotcode-Test.Robots.MyRobot1.MyRobot1 and Robotcode-Test.Robots.MyRobot2.MyRobot2 and that is kinda weird, why does it work differently than using Run and Debug tab? I would totally expect it to be MyRobot1 and ´MyRobot2` or at least the same for both Run and Debug and ctrl-shift-p menu.

Then the most important for me: running just one test from some suite using the green play button on the left of the Test Case name (where there is place for breakpoints on rows where there is no play button). The suite name there is Robotcode-Test.Robots.MyRobot1.MyRobot1 and I expect it to be MyRobot1.

On my project there is configuration and it is handled based on suite name. So there is some configuration for MyRobot1 and some configuration for MyRobot2 so I would like to have those suite names stay the same as they have been before when using robotframework-lsp.

I have tried using that in robot.toml

paths = [ "robots/MyRobot1/MyRobot1.robot" ]

and with that I get correct suite name for MyRobot1, but I need to change the robot.toml every time I need to run some test from the other suite.

Using something like that in settings.json

"robotcode.robot.paths": [ "robots/MyRobot1/MyRobot1.robot" ]

I get the same thing done, but again I need to change that every time I need to run something from the other suite.

I think that using launch.json would get what I want as it supports vs code variables like ${relativeFile}. I have tried the following setup:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "RobotCode: Run Current",
            "type": "robotcode",
            "request": "launch",
            "cwd": "${workspaceFolder}",
            "target": "${file}"
        },
        {
            "name": "RobotCode: Run All",
            "type": "robotcode",
            "request": "launch",
            "cwd": "${workspaceFolder}",
            "target": "."
        },
        {
            "name": "RobotCode: Default",
            "type": "robotcode",
            "request": "launch",
            "purpose": "default",
            "presentation": {
                "hidden": true
            },
            "pythonConfiguration": "RobotCode: Python",
            "paths": [ "robots/MyRobot1/MyRobot1.robot" ]
        },
        {
            "name": "RobotCode: Python",
            "type": "debugpy",
            "request": "attach",
            "presentation": {
                "hidden": true
            }
        }
    ]
}

but it seems that ´paths´ in launch.json does not work (at least in the same way as in robot.toml and settings.json. Other than that ´paths´ there in the default purpose is default launch.json for RobotCode, I think.

So do you know if there is some way to achieve the suite name that I want?

[d-biehl]

Thanks for the detailed explanation. I think the actual issue is that your project configuration depends on suite names like MyRobot1 or MyRobot2, while different execution methods create different Robot Framework suite hierarchies.

In Robot Framework, suites are created from files and directories. The path passed to robot defines the top-level suite:

robot robots/MyRobot1/MyRobot1.robot

runs the file as the root suite, so the suite name is MyRobot1.

Running from a higher root, for example:

robot .

creates the directory-based hierarchy, for example:

Robotcode-Test.Robots.MyRobot1.MyRobot1

Both are valid, but they are not equivalent.

The usual Robot Framework approach is to keep a stable execution root and select the tests, suites, or tags to run with filters such as --test, --suite, --include, or --exclude. That keeps the surrounding suite context intact. This matters because directory suites can have __init__.robot files with suite setup, teardown, metadata, tags, and other initialization logic. These files are only applied when the corresponding directories are part of the executed suite hierarchy. Using a stable suite hierarchy is also important because it enables common Robot Framework workflows based on tags, for example running all smoke or regression tests while excluding tests tagged as wip or work-in-progress. It also makes reports, merged results, statistics, and historical test analysis more consistent across runs.

That is the main difference between the two workflows here:

• A launch configuration with "target": "${file}" runs the current file directly as the root suite.
• The Test Explorer / gutter play button workflow uses RobotCode’s configured discovery root and then selects the requested file, suite, or test from that model.

For regular VS Code usage, I recommend the second workflow: use the green run buttons, the Test Explorer, or the corresponding VS Code test commands / shortcuts. The exact shortcuts depend on your keybindings, but this workflow follows the stable-root-plus-selection model.

Because of that, I would not make robotcode.robot.paths dynamic based on the currently opened file. It would make the same test run with different suite hierarchies depending on how it was started, and it could also change which __init__.robot files are applied.

If you prefer running files directly with a launch configuration or F5, that is also valid, but then I would use that workflow consistently and accept that the current file is the execution root.

Robot Framework also allows suite names to be customized with the Name setting or with --name, but the full suite name still depends on the execution hierarchy. Therefore I would avoid using the full suite name as the key for project-specific configuration. If configuration belongs to MyRobot1, make that explicit instead, for example with suite metadata, a suite variable, tags, a variable file, or the suite source path.

So I would not solve this with dynamic paths. I would choose one execution workflow and avoid coupling project configuration to suite long names that change with the execution root.