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.
Wrote projects/demo-shop/envs/qa.yaml by copying staging.yaml and changing the URLs. Then:
sdods run -p demo-shop -e qa -l api✖ ENV_NOT_FOUND: Environment "qa" is not in envs.available [local, staging] for project demo-shop.
hint: Add "qa" to envs.available in sdods.project.yaml and create envs/qa.yaml.
docs: https://docs.sdods.com/docs/guides/configurationThe file is right there. Why does it also need declaring?
Accepted answer
Because the declaration is the list, and the file is the detail. envs.available is what project list, the CI matrix and the web UI enumerate; a stray file in envs/ is not an environment until the project says it is.
envs:
default: staging
available: [local, staging, qa]The order matters for the error you get next: availability is checked first, file existence second. So if you had done it the other way round — declared qa with no file — you would have seen
✖ ENV_NOT_FOUND: Environment "qa" has no file at /work/shop-tests/projects/demo-shop/envs/qa.yamlTwo errors, two different halves of the same mistake.
There is a command that does both halves and keeps the comments in your project yaml intact:
sdods env add qa -p demo-shop --ui-url https://qa.example.com --api-url https://api-qa.example.comIt writes envs/qa.yaml and appends qa to envs.available. Add --default if it should become the default environment.
Also worth knowing that -e is not the only way in. The environment is picked in this order: the -e flag, then whatever the caller passed programmatically, then SDODS_ENV, then envs.default from the project file. A leftover SDODS_ENV=qa in a shell profile produces exactly this error with no -e in sight.
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.