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.
Twice this month a pull request that only touched an environment file went green on review and then took the nightly down. Both times it was something a schema check would have caught in a second.
What is the right gate to add, and where in the pipeline does it go?
Accepted answer
Its own step, before anything installs a browser:
sdods config validateThat resolves every project against every environment it declares — YAML parse, schema, ${VAR} resolution, secret literals, the workspace checks — and exits 2 on the first failure. It runs in about a second and needs nothing but the repo.
One thing to get right: on an agent there are no .env files, so every reference has to come from the job environment. That is a feature here — validate will fail loudly on a variable your laptop happens to have and the agent does not, which is the class of bug that otherwise only appears at three in the morning.
Then order the rest by cost: validate (exit 2), lint (exit 3), run (exit 1).
We pair it with a machine check on the same step:
sdods doctor --jsonValidate answers "is the configuration coherent"; doctor answers "can this machine act on it" — node, browsers, the variables per project and environment, the database. On a fresh runner image the second one is what actually breaks.
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.