Remove .env files from source control

[stann1]

.env files are meant to be used on the individual local env and keeping them out of source control is a good practice. Makes the local setup much easier due to the fact that some services and debuggers rely on the .env file and ignore any overloads.

For the deployment environments, there is always a better way to provide the env vars (yml manifests, ci/cd variables, etc..)

[kachar]

@stann1 We generally use the .env file for the common shared environment variables.

By default docker-compose only understands the .env file (See https://docs.docker.com/compose/environment-variables/#the-env-file)

One possible solution is to remove .env but have a mirror copy of it in .env.example next to .env.local.example.

I feel that having the two files side by side will be more complex for newcomers.

We might also ask @imilchev and @dimitur2204 for their opinion on the topic.

[stann1]

I think that this is much more appropriate. Generally speaking .env files are specific to the the machine they are on, so they should not be source controlled. For example, currently my machine requires the use of different ports because of conflicts, so I have to modify my .env file but make sure to not commit it. The same thing is possible on a server.

But we can always have a config that can be overriden by env files, or have everything tin the example, as you said

[dimitur2204]

I think that this is much more appropriate. Generally speaking .env files are specific to the the machine they are on, so they should not be source controlled. For example, currently my machine requires the use of different ports because of conflicts, so I have to modify my .env file but make sure to not commit it. The same thing is possible on a server.

But we can always have a config that can be overriden by env files, or have everything tin the example, as you said

The thing is we dont' have anything secret in our .env file, which I suppose would usually be the case.

And considering docker-compose only understands .env., then making a .env.example is just another step we need to write down at in the README.

What we can maybe do is remove the .env.local.example generally and put everything from it in the .env.example and remove the .env from the source control and run the repo this way.

[kachar]

What we can maybe do is remove the .env.local.example generally and put everything from it in the .env.example and remove the .env from the source control and run the repo this way.

@dimitur2204 Sounds like a good solution to me - only one file - .env.example and no .env.local*