Closed webpigeon closed 4 months ago
I propose even a step farther - not having .env at all in the codebase (.env.example, sure), but rather base64 encoding the .env file into the github secrets manager for a specific environment, and loading it up during github actions.
Would some of this be mitigated with secret: true
setting for the relevant copier.yml
keys? This wouldn't copy them to .copier-answers.yml
.
I too am confused as to why .env
isn't in .gitignore
- although I'm guessing this has to do with the somewhat non-standard decision to share .gitignore
between the template and the generated project? Like, in a copier template, I would generally expect all the directories-to-be-copied to be nested under {{project_name}}
, and have a separate .gitignore
there.
...I think I see why secret: true
wasn't used - .copier/update_dotenv.py
relies on the presence of secrets in the answer file. One way to avoid this dependency would be to make update_dotenv.py
CLI-argument friendly, and pass the secrets directly in the task definition in copier.yml
.
Another option: use .env.jinja
instead, and add .env
to .gitignore
? That way, secret values are rendered at generate time in .env
, and then git init && git add -A
after generation contains neither the new .env
nor secrets in the .copier-answers.yml
.
Edit: This option does make .copier/update_dotenv.py
useless, but I don't think that's a problem - in fact, that allows the template to be used without --trust
.
After running the installation instructions, there appears to be two files containing secrets. Neither of which is in the gitignore and one of which is already versioned:
Both of these files contain sensitive data that should not appear in version control histories (including tokens and passwords). These files should not be versioned for security reasons, in addition,
.env
contents will vary across development machines (eg, passwords for staging systems).I suggest splitting the data into two files, one which is safe to version and one which is not.