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 wanted the nightly to fail on lint warnings, so somebody moved the flag onto the run:
sdods run -p shop -e staging -l ui -t @regression --strictIt ran, it passed, and the eleven warnings we were trying to catch are still there. On sdods lint --strict the same eleven give exit 3. Same flag name, different behaviour?
Same name, different command, genuinely different meaning.
On sdods lint, --strict means treat warnings as errors — the exit becomes 3 when there are warnings and no errors.
On sdods run, --strict is the HAR modifier. It pairs with --har-replay and means abort on any request that is not in the recorded file, so the run is properly offline instead of quietly falling through to the network. Nothing to do with lint at all, which is why yours did nothing: without --har-replay there was nothing for it to modify.
What you want is the two as separate steps:
sdods lint -p shop --strictsdods run -p shop -e staging -l ui -t @regressionWhich is better anyway — a lint failure and a test failure are different problems, and as separate steps the pipeline tells you which one you have without reading the log.
Before you turn --strict on for a project with eleven existing warnings, look at what they are. A couple of the warning rules describe legitimate intermediate states — @har: naming a file not yet recorded is the usual one, and an outline missing its # title-format: comment is cosmetic. Making those hard failures on day one tends to produce an exemption list, and an exemption list is how a strict gate becomes decorative.
Clear them first, then turn it on, then it stays at zero.
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.