If I pass --process nightly-regression and -t @smoke, which one wins?
Example threads. These questions and answers were written by the SDODS team to document real problems and how to fix them. The people named are illustrative, not real users. Questions asked on this site are marked new.
We have a nightly-regression process that pins the env, the layers, the browsers and a tag expression. Last night I wanted the same recipe but only the smoke scenarios, so I ran:
bash
sdods run -p demo-shop --process nightly-regression -t @smoke
It ran something. I cannot tell from the output whether it used my @smoke or the process's tag expression, and I do not want to find out the wrong way on a release gate. Is passing both defined behaviour, or should I stop doing it?
It is defined, and your flag wins. A process supplies **defaults for the flags you did not give**, so anything explicit on the command line overrides the recipe:
-t / -e / --retries / -w / --fail-on-flaky override the process when present
-l, -b and -m are lists, so the process's values are used only when you pass none — one -b chromium replaces the recipe's whole browser list rather than narrowing it
So your run was @smoke, with the env, layers and browsers still coming from nightly-regression. That is usually what people want.
Two things to watch. Because lists replace rather than intersect, --process release-gate -b chromium is not "the release gate, chromium only" if the gate also pins modules you forgot about — it is the gate with a one-browser list. And the run record stores the process name either way, so a dashboard will file that @smoke run under nightly-regression alongside the real ones.
If you want to see what you are actually about to run:
bash
sdods run -p demo-shop --process nightly-regression -t @smoke --list
--list resolves everything and prints the scenarios without running them.