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.
PR checks take 40 minutes because we run the whole suite on every push, and a typical PR touches one module. I was expecting something like
sdods run -p portal --since origin/mainbut that is not a flag. There is clearly change-impact analysis somewhere — is it reachable from run?
It is not. sdods run has no --since and no equivalent. The analysis exists, but only as the analyze_change_impact tool on the MCP server — and nothing feeds its output back into the runner. Open issue; the ask is exactly your flag.
Two-step version that works today: call the tool from CI, take the modules or tags it reports, and pass them to run:
sdods run -p portal -m <module> -m <module> -t @regressionThat does cut the time. It just makes your CI job responsible for wiring together two things that should be one.
We do that, and the awkward part is not the plumbing, it is the fallback.
When the tool returns nothing — a change it cannot map, a config-only PR, a failure in the step itself — you have to choose between running everything (and losing the saving on exactly the changes you understand least) and running nothing. Get that branch wrong and you have a green PR check that tested nothing, quietly, for weeks. Ours defaults to the full suite on an empty result and shouts about it in the job summary.
If you build this, spend your care there rather than on the selection.
Wrap commands and output in triple backticks and they will render as a code block.
Checking whether you’re signed in…
Have a different question? Ask it.