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 added projects/shop/envs/qa.yaml last week and it works — sdods run -p shop -e qa -l api runs against it. But the moment I pin a scenario to it:
@api @regression @env:qa
Scenario: The rate limiter returns 429 after the tenth call✖ features/api/rate-limit.feature:12 tags/env @env:qa is not in envs.available (local, staging).The file exists. What else is it looking at?
Accepted answer
The declared list, not the directory. Add it to the project yaml:
envs:
default: staging
available: [local, staging, qa]The env file being loadable and the env being a declared target are two different facts on purpose — you can keep a scratch env file on disk without it becoming something scenarios are allowed to pin themselves to, and envs.available is what the run viewer, the scheduler and this lint rule all read.
Same list, same message, everywhere: the parenthesised names in the error are just envs.available joined.
While you are in there — think about whether you want @env:qa at all. It is a real restriction, so that scenario silently does not run on staging or local, and six months later somebody wonders why coverage for the rate limiter is missing. We ended up using it only for things that are genuinely impossible elsewhere (a third-party sandbox that only exists in one env) and leaving everything else unpinned.
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.