← All questions

sdods run refuses to start with LINT_FAILED — can I run anyway while I fix the tags?

sdods run -p shop -e staging -l ui -t @smoke

✖ features/checkout/checkout.feature:22  tags/suite  Scenario must carry exactly one suite tag (@smoke, @regression, @sanity); found none.
✖ features/checkout/checkout.feature:38  tags/layer  Scenario must carry exactly one layer tag (@ui, @api, @hybrid); found none.
2 feature file(s), 2 error(s), 0 warning(s)
✖ LINT_FAILED: 2 lint error(s) in project shop. Fix them or pass --no-lint.

3 answers

• 24votes✓

  Accepted answer

  Because the specs are generated from the whole project before anything is selected, and a scenario with no layer tag has no run target to be generated into. Selecting a subset happens after that, so it cannot rescue a file that failed to compile into anything.

  The escape hatch is in the message:

  bashCopy

  sdods run -p shop -e staging -l ui -t @smoke --no-lint

  That is the right tool for exactly your situation and the wrong tool in a pipeline. A run started with --no-lint will happily not run scenarios whose tags are broken, which is the silent-zero failure mode all over again.

  Note the exit code is 3, not 1, when the run stops this way — same code as sdods lint itself. A pipeline that distinguishes them can say "your features are wrong" instead of "your tests failed".

  RNanswered by Reeta Nandalmaintainer41,280 · 2 Apr 2025
• 10votes

  While you are mid-refactor, lint the one file you are editing rather than the project:

  bashCopy

  sdods lint -p shop --file projects/shop/features/checkout/checkout.feature

  --file is repeatable, and bare paths work as positional arguments too. Much shorter feedback loop than the full project, and when it comes back clean you know sdods run will get past the gate.

  

  AVanswered by Anouk de Vries238 · 3 Apr 2025
• 8votes

  One asymmetry that confused us for a while: sdods run only prints lint warnings when you pass --verbose. Errors always print because they stop the run; warnings are held back so a normal run is not buried in output about files you are not touching.

  So a project can accumulate warnings for months without anyone running sdods lint seeing them. Run the linter on its own periodically, or with --strict in a nightly job, otherwise "the run was clean" and "the features are clean" quietly stop meaning the same thing.

  LHanswered by Lena Hartwig10,388 · 9 Apr 2025