← All questions

Secret literal at "env.vars.password" — I want the password in the env file, why is that refused?

vars:
  defaultProduct: Sauce Labs Backpack
  password: hunter2

✖ CONFIG_SECRET_LITERAL: Secret literal at "env.vars.password". Use ${VAR} and put the value in .env.<env>.
  hint: Replace the value with "${PASSWORD}" and add PASSWORD=... to your .env file.
  docs: https://docs.sdods.com/docs/guides/configuration

2 answers

• 49votes✓

  Accepted answer

  No override, on purpose. The environment files are committed; a key whose name looks like a secret has to hold a ${VAR} reference and nothing else.

  Do it the way the shipped demo does:

  yamlCopy

  vars:
    standardPassword: "${DEMO_SHOP_PASSWORD:-secret_sauce}"

  bashCopy

  echo "DEMO_SHOP_PASSWORD=hunter2" >> projects/demo-shop/.env.staging

  The :- form gives you a fallback, so a checkout with no .env.staging still runs against the public demo site. Steps read it as {{standardPassword}} either way.

  RNanswered by Reeta Nandalmaintainer41,280 · 24 Nov 2020
• 12votes

  The reason the rule has no escape hatch is that the same check is what lets us promise the yaml is safe to commit and safe to paste into an issue. Once one project has a literal in it, nobody trusts the rest.

  Keep a .env.example next to the project with the names and no values — it documents what a new machine needs without carrying anything.

  PVanswered by Priya Venkateshmaintainer29,604 · 27 Nov 2020