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.
I tagged our happy-path checkout scenario with both suite tags because I want it in the pull-request smoke run and in the nightly regression run. Lint disagrees:
✖ features/cart/checkout.feature:18 tags/suite Scenario must carry exactly one suite tag (@smoke, @regression, @sanity); found @smoke @regression.
1 feature file(s), 1 error(s), 0 warning(s)Surely wanting a scenario in two suites is normal? Or am I meant to duplicate the scenario?
Accepted answer
Do not duplicate it. The suite tag is a classification, not a subscription list — it answers "what kind of check is this", and a scenario that is both the smoke check and the regression check is really just the smoke check.
Selection is done by the tag expression, not by the tag alone. Your nightly run does not have to say -t @regression:
sdods run -p demo-shop -t "@smoke or @regression"Or put it in the project yaml so nobody has to remember it:
processes:
- name: release-gate
title: Release gate
trigger: release
tags: '@smoke or @regression'
browsers: [chromium, firefox, webkit]then sdods run -p demo-shop --process release-gate.
The other reason for exactly one is the screenshot policy, which is keyed on the suite tag. With two of them there is no single answer to "how much do we capture for this scenario".
We hit this too and settled on a rule that has held up: if the scenario is allowed to break the pull request, it is @smoke. Everything else is @regression. Then the nightly expression is or and nothing needs two tags.
Worth knowing the error text is generated from your project, not hardcoded — the list in the message comes from tags.suites. If you renamed suites, the message names your names.
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.