Symfony recipe and .env.local

[SiMoSiMo2]

Hello, I'm a bit confused.
The .env.local file is used to locally override the values of the .env file. The .env.local file is added to the .gitignore because I want it to stay local and not versioned.
Why then is it added by default to the Symfony recipe and therefore I also find it on the production server after doing a release with deployer?
The file should remain local, because that's what it is for.

deployer/recipe/symfony.php

Line 20 in 88f6e42

'.env.local'

[Schrank]

Hi @SiMoSiMo2 and thanks for your comment!

The idea and concept is, that you version a .env with some default/example configuration and overwrite everything with .env.local.

But you want to overwrite on the server as well and there is only two types of files on the server:

• versioned files
• shared files

So .env.local is a shared file. It is NOT from your git, but created on the first deployment in shared/.env.local and symlinked into your release, so you can add your production configuration to it.

I'm not into pure symfony, but I assume (correct me if I'm wrong): if you don't add anything to the file, your .env is used.

I hope this answers your question!

[SiMoSiMo2]

The idea is wrong, to me.
The .env.local file should remain local.
Its purpose is to override the default parameters contained in the .env file with values used only locally.

I'll give you an example.
Inside the .env file I have some keys and the URL of the DB. In the .env.local file I replace them with the local version of this information. If deployer brings to production the .env.local file SF in production will read this file and then use my local keys and point to the URL of the local DB and not the production one as it should.
The .env.local file contains the local values and this is why it is added to the .gitignore.

Look at this:
https://symfony.com/doc/current/the-fast-track/en/5-debug.html#managing-environment-configurations

[Schrank]

I think we might have two misunderstandings:

1. deployer is NOT bringing YOUR env.local to the production system. it is creating an EMPTY file you can fill (automatically or manually) with any data you want to overwrite from your .env file.
2. In the context of Symfony "locally" doesn't mean your local development environment, but the local system, be it your laptop, a staging server or the production environment.

So my understaing of the process is the following:

• you add .env to your git
• .env.local is ignored
• you deploy to your server
• with the deployment, .env comes from git
• .env.local does NOT
• you fill or fill not .env.local on the server (be it test, stage, prod or whatever) with the values needed for the environment.

(I'm really fearful to sound arrogant, so please bear with me, trying to help)
If you don't use .env.local this way, how do you bring the production configuration like db passwords, CDN userdata, etc. to production? Because the alternative I see is to put it in the .env and then your credentials are in the git and this should not be the case.

[SiMoSiMo2]

Don't worry, I understand that you are trying to explain your concept to me and I've got it.

Ok, probably it is my mistake. I thought that the list of files indicated into the shared_files meant bringing the indicated file (file and content) to the destination server, while instead it seems it only serves to indicate which files are shared ... but then the content of these files must be set up on the destination server.
This means that if I make some changes to my .env file (which is not versioned) I have to repeat these changes manually also to the .env file on the production server; it is not enough to indicate the .env file inside shared_files to tell to deployer "this file is not versioned, but take it from the source and copy it to the destination". Is there a feature that does something like this?

[Schrank]

Is there a feature, that updates your production .env with the local one? No. But it should be relatively easy to implement a task which does exactly that, upload already exists: https://github.com/deployphp/deployer/blob/master/src/functions.php#L545

And there is a pull request I'm trying to take care for months which at least doesn't create an empty shared file, but instead uses on the first run the one from the repository (#2267), maybe this is interesting for you as well :-)