Skip to content

[FrameworkBundle] Add inlined env vars into debug:container output #49336

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

valtzu
Copy link
Contributor

@valtzu valtzu commented Feb 11, 2023

Q A
Branch? 6.3
Bug fix? no
New feature? yes
Deprecations? no
License MIT
Doc PR symfony/symfony-docs#...

Currently environment variables that are consumed during build process are not visible to debug:container command. It took a long time to realize changes to runtime environment variables wont have any effect because those vars are inlined during build process of the DI container.

This MR shows all env vars that any extension resolved during compilation of the container.

Example:

Given the following config:

parameters:
    env(LOG_LEVEL): info

services:
    _defaults:
        bind:
            $logLevel: '%env(string:LOG_LEVEL)%'

monolog:
    handlers:
        main:
            type: stream
            path: "%kernel.logs_dir%/%kernel.environment%.log"
            level: '%env(LOG_LEVEL)%'

With empty cache directory, 1st time we run the cli command, it'll build the container:

$ LOG_LEVEL=notice bin/console debug:container --env-vars

Symfony Container Environment Variables
=======================================

 --------------------- --------------- ------------------------------------ 
  Name                  Default value   Real value                          
 --------------------- --------------- ------------------------------------ 
  LOG_LEVEL (inlined)   n/a             "notice"                            
  LOG_LEVEL             "info"          "notice"     

Now, if we run the command with different LOG_LEVEL value, we see that the inlined value stays the same.

$ LOG_LEVEL=debug bin/console debug:container --env-vars

Symfony Container Environment Variables
=======================================

 --------------------- --------------- ------------------------------------ 
  Name                  Default value   Real value                          
 --------------------- --------------- ------------------------------------ 
  LOG_LEVEL (inlined)   n/a             "notice"                            
  LOG_LEVEL             "info"          "debug"                             

This would mean that Monolog uses LOG_LEVEL=notice while the services where $logLevel is injected would receive debug value.

And with more verbose --env-var flag

$ LOG_LEVEL=debug bin/console debug:container --env-var LOG_LEVEL

Symfony Container Environment Variables
=======================================

 // Displaying detailed environment variable usage matching LOG_LEVEL                                                   

%env(string:LOG_LEVEL)%
-----------------------

 --------------- ---------- 
  Inlined value   "notice"  
 --------------- ---------- 

%env(string:LOG_LEVEL)%
-----------------------

 ----------------- --------- 
  Default value     "info"   
  Real value        "debug"  
  Processed value   "debug"  
 ----------------- --------- 

In my opinion better solution would be to deny the usage of resolveEnvPlaceholders before container is built but that would of course break backwards compatibility.

@carsonbot
Copy link

Hey!

To help keep things organized, we don't allow "Draft" pull requests. Could you please click the "ready for review" button or close this PR and open a new one when you are done?

Note that a pull request does not have to be "perfect" or "ready for merge" when you first open it. We just want it to be ready for a first review.

Cheers!

Carsonbot

@valtzu valtzu marked this pull request as ready for review February 11, 2023 14:26
@carsonbot carsonbot added this to the 6.3 milestone Feb 11, 2023
@carsonbot
Copy link

Hey!

I see that this is your first PR. That is great! Welcome!

Symfony has a contribution guide which I suggest you to read.

In short:

  • Always add tests
  • Keep backward compatibility (see https://symfony.com/bc).
  • Bug fixes must be submitted against the lowest maintained branch where they apply (see https://symfony.com/releases)
  • Features and deprecations must be submitted against the 6.3 branch.

Review the GitHub status checks of your pull request and try to solve the reported issues. If some tests are failing, try to see if they are failing because of this change.

When two Symfony core team members approve this change, it will be merged and you will become an official Symfony contributor!
If this PR is merged in a lower version branch, it will be merged up to all maintained branches within a few days.

I am going to sit back now and wait for the reviews.

Cheers!

Carsonbot

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants