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.
The demo staging file ships with this:
vars:
standardPassword: "${DEMO_SHOP_PASSWORD:-secret_sauce}"Two questions. What is the :- part, and why is a key called standardPassword allowed to carry a literal password as a fallback when a plain password: secret_sauce is rejected?
Accepted answer
${VAR:-default} uses the default when the variable is absent from both the dotenv layer and the process environment. Without the :- an absent variable is a hard error; with it, resolution just falls through.
And yes, the secret check accepts it. The rule is that the value must be exactly one ${...} reference and nothing else — a reference with a default still is one. The check is about not committing a value under a name that looks like a credential; it does not try to be a static analysis of what the default happens to be.
It is only defensible in the demo because the target is a public sandbox and the fallback is that site's published password. For anything real, drop the default: you want the loud failure on a machine where the variable is missing, not a silent run against the wrong credential.
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.