Investigate strategy for setting environment variables

[brandongregoryscott]

Recently some of the engineers have desired an easier way to set environment variables when running commands through the cli. While this could be baked in directly to our current use-case (and-cli dotnet), it might make more sense for there to be a 'global' option where you can set environment variables for any command, such as:

and-cli dotnet --env ASPNETCORE_ENVIRONMENT=Working

I assume we would want the ability to set multiple variables in one command: and-cli dotnet --env ASPNETCORE_ENVIRONMENT="Working" --env AllowedHosts="*"

Nested environment variables should use the Object__NestedVariable syntax, such as: and-cli dotnet --env ConnectionStrings__ProjectDb="..."

If we build it as a 'global' option instead of just into the dotnet command, we would be able to set variables when running webpack, webpack-test etc., without having to update each individual command.

Some of the engineers expressed preference in these variables only persisting for the command run they were run with, not for the entire shell session. I could see value in both. For clearing them out after the command exits, you'd need to do something like this (example bash commands):

bscot@BSCOTT-PC ~ -> export SOMEVAR=SOMEVALUE; and-cli dotnet; unset SOMEVAR

I'm not set on this specific naming convention, but maybe --shell-env SOMEVAR=SOMEVALUE could be the standard 'sticky' environment variable which persists for the shell session, where --env or -e could be the 'process' environment variable which is immediately unset upon exit.

ShellJS provides a wrapper around Node's process.env, which you can index into with just a string: see http://documentup.com/shelljs/shelljs#envvar_name

[wintondeshong]

Note: Ensure forwarding of environment variables is done in a cross-platform manner (ie. cross-env)

[wintondeshong]

While I can see the explicit command param useful, the integration of dotenv will eventually occur which will allow for project-level, developer/local/etc..., environment specific config files that pre-load environment variables. I'm totally cool if we do both. Merely saying to consider if we feel dotenv will be as good/if not better for folks use cases, perhaps we consider doing that first?

[brandongregoryscott]

That's a good point. How do you think that should work? Would it automatically look for *.env file(s) in the current directory and decide which one it should use based on an existing environment variable? (such as ASPNETCORE_ENVIRONMENT=Development would load development.env)

[wintondeshong]

Totally up for discussion, but here are some initial thoughts on functionality based on how I've used .env files on varying projects...

CLI environment "install [?template]" comand

• would generate a template .env file in your current directory based on .env.sample shipped with and-cli itself
• would add exclude to project .gitignore of .env so it doesn't get checked in. common pattern is for team to check in .env.{template} with safe key=value defaults to ease configuration. But any sensitive ones are managed with other means (password lockers, etc...)

CLI environment "switch [template]" command

• simply takes a template (if it exists) of .env.{template} and overwrites .env with it.
• bonus feature could be interactive mode: when switching, it parses the file and anywhere there isn't a default value (key=), it asks a question. If that variable has a comment above it, it would pipe that into the prompt as well.

CLI leveraging of .env files

• CLI would load .env file found in project directory (indicated by .git directory)
• The project team could keep as many .env.{xyz} named files in the repo checked in to serve as merely a template. From there if they want to use one they cp .env.{desired-version} .env.

Should we have .env file inheritance? While dotnet core added this ability to inherit variables through different levels of config (reminiscent of web.config transforms), I honestly feel it lends to mismanagement and confusion. I feel it would probably be best to all be one flat version of properties.

The maintainers for dotenv weigh in on this as well...

Should I have multiple .env files? No. We strongly recommend against having a "main" .env file and an "environment" .env file like .env.test. Your config should vary between deploys, and you should not be sharing values between environments.

In a twelve-factor app, env vars are granular controls, each fully orthogonal to other env vars. They are never grouped together as “environments”, but instead are independently managed for each deploy. This is a model that scales up smoothly as the app naturally expands into more deploys over its lifetime.

– The Twelve-Factor App