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 are onboarding six more testers and the current answer is "ask someone in chat for the staging password". I would like to write down one way of doing this that survives contact with people who are not going to read a wiki page.
What does a working setup look like — files, gitignore, CI, and what a new laptop has to do on day one?
Four rules and the tooling enforces two of them for you.
${VAR} or resolution refuses to start, so this one polices itself..env.<env> beside the project, and .env* is gitignored except .env.example..env.example lists every name with no value. It is the day-one checklist and it is reviewed like code, so a new variable arrives with its documentation..env
.env.*
!.env.exampleDay one for a new laptop is then: clone, copy .env.example to .env.staging, fill in the four values, run sdods doctor -p demo-shop.
Adding the CI half properly, because this is where people reach for a committed file.
Export in the job environment, do not write a .env in a build step. Two reasons: an exported variable outranks any file, so a stray file on the agent cannot shadow it; and a file written by a step tends to survive into the artefact upload.
Then put a validation step before the run so a missing secret fails in five seconds with a name, rather than twenty minutes in with an auth failure:
sdods config validateOne thing people miss: integrations and MCP servers store the names of variables rather than their values — tokenEnv, emailEnv, envFrom, headersFrom. So the GitHub and Jira config is safe to commit in full, and if you find yourself pasting a token into one of those fields you are in the wrong field.
Logs, HAR files and screenshots are redacted by the same key pattern plus your mask selectors, which is worth knowing before you attach a trace to a ticket.
Counterpoint on rule 3 only: we found .env.example drifts unless something checks it. We added a step that greps the referenced variable names out of the yaml and diffs them against the example file. Crude, but it caught two missing entries in the first month.
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.