Command-Line Selection, Tag Expressions, Reruns, and Execution Profiles: Configuration, Design Patterns, and Trade-Offs

1. The design principle: minimize invisible configuration

The cheapest command is not always the shortest command. A short wrapper with hidden defaults can be harder to diagnose than a longer explicit invocation. A good execution interface answers five questions quickly: what source is parsed, what selectors apply, what configuration values differ, where outputs go, and what layer supplied each option.

2. Decision table

3. CLI flags versus argument files

Direct CLI is ideal while exploring because every option is visible in shell history. An argument file becomes valuable when the same options are a named team contract. Robot Framework inserts the file contents exactly where --argumentfile appears, so precedence still has an order.

# defaults.args
--outputdir results/default
--variable TARGET_ENV:local
tests

# Later CLI value overrides the earlier single-valued outputdir.
python -m robot -A defaults.args --outputdir results/incident

Because an argument file can also contain the data source, decide whether your team treats “project root” as part of the contract. If yes, document it and enforce it in launch scripts. If not, use normalized paths rather than a brittle chain of ../../.

4. Tags versus structural selection

Directories and suites encode structural ownership; tags encode orthogonal attributes. A payments suite is a good structural unit. smoke, regression, slow, and owner-platform are good cross-cutting tags. Do not make the same concept simultaneously depend on both path and tag unless the redundancy is intentional and tested.

Selection combines criteria. A command such as --suite Payments --include smoke means “smoke tests inside Payments,” not “Payments plus smoke tests elsewhere.” This makes selectors composable but also makes zero-selection bugs easy to create when assumptions differ.

5. Include/exclude versus skip semantics

Use include/exclude to define the execution population. Use skip to preserve an explicit non-execution status. In CI, the policy question is whether skipped tests count as acceptable unavailable coverage, debt, or a gate failure. Robot records status; your release governance interprets it.

6. Failed-only rerun versus full rerun

A rerun is never a generic retry loop. It is a second execution with provenance. If the failure is caused by a shared environment outage, a full rerun after documented recovery may be more honest than selecting only failures. If one deterministic defect is fixed, failed-only rerun may be appropriate.

7. Many environment flags versus one documented command

Variables belong to configuration, but a forest of --variable flags can become unreviewable. Prefer a small set of explicit high-level inputs and derive implementation details in a variable file/resource/library at the right boundary. Never encode real secrets in argument files. CI should inject secret values through its secret system into a Secret-aware or otherwise protected runtime path, with logging reviewed separately.

8. Optional RobotCode profile layer, clearly separated

RobotCode 2.7.0 provides robot.toml and profiles. It is useful when a team wants structured profile inheritance and a single tool across editor and CLI, but it changes the dependency contract: Python 3.10+ and RobotCode runner support are now required.

# robot.toml -- optional external layer
paths = ["tests"]
output-dir = "results/default"

[profiles.smoke]
description = "Fast local smoke slice"
extend-includes = ["smoke"]

[profiles.regression]
description = "Regression without slow"
extend-includes = ["regression"]
extend-excludes = ["slow"]

robotcode profiles list
robotcode profiles show smoke
robotcode -p smoke run

RobotCode configuration loading is layered: global user configuration, project pyproject.toml, project robot.toml, then project-local .robot.toml. Profiles are then resolved by their precedence/order rules. Therefore “works on my machine” can come from a local override. Team CI should either forbid unexpected local config or explicitly display resolved configuration.

9. Committed profile versus local override

Do not place required CI behavior only in .robot.toml. Do not put credentials in any of these committed/plain-text files. For a production incident, capture the resolved RobotCode profile and the exact command, not merely the profile name.

10. Runtime and parallelism trade-offs

Selection can reduce Robot keyword/external-system time, but it does not necessarily reduce parse/import cost unless file parsing itself is narrowed. A smoke tag still requires Robot to discover relevant source. Later, Pabot will add worker scheduling and resource contention; do not confuse “selected 50 tests” with “50 tests are safe to run concurrently.” Outputs from different workers/profiles also need distinct directories before merging.

11. Worked scenario: choose a release contract

A team has 900 tests in 30 suites. Pull requests need about 40 smoke tests, nightlies need 500 regression tests but not 80 slow ones, and developers need one-test debugging. A robust design is: tags for smoke/regression/slow; direct --test for one-off debugging; committed core argument files for CI if no extra tool is desired; or committed RobotCode profiles if RobotCode is an explicit team dependency. Environment is supplied via variables, outputs use unique directories, and failed-only reruns are a separately governed follow-up.

Knowledge check

Summary and bridge

The design goal is not maximum configuration sophistication; it is minimum ambiguity. Lesson 4 deliberately breaks selection, rerun identity, cwd assumptions, and profile precedence so you can diagnose the layer that failed without hiding evidence.

References and version anchors

• Robot Framework 7.4.2 User Guide — CLI option syntax, name/tag selection, argument files, reruns, skip/exclude semantics, and result post-processing.
• Robot Framework 7.4.2 on PyPI — stable release and Python compatibility anchor.
• RobotCode configuration, RobotCode CLI reference, and RobotCode 2.7.0 package metadata — optional external layer.