[DI] Select specific key from an array resolved env var #27157
Conversation
4f06e6e to
f8ea2b5
Compare
|
Looks good, thank you! You'd just need to add "key" to "getProvidedTypes()" - and add tests now to verify this works as expected of course as you mentionned. |
0a3a726 to
8d311e8
Compare
|
Tests have been added, |
| @@ -41,6 +41,7 @@ public static function getProvidedTypes() | |||
| 'float' => 'float', | |||
| 'int' => 'int', | |||
| 'json' => 'array', | |||
| 'key' => 'string', | |||
There was a problem hiding this comment.
It could be anything, like const above
There was a problem hiding this comment.
const is not allowed in the returned types (or at least, that is what the tests tell me when I add it). A const in only a const when the processor has interpreted a string as such right?
Would updated this to 'key' => 'bool|int|float|string|array', make sense?
There was a problem hiding this comment.
What about fetch for a name? Tend to prefer it over key..
There was a problem hiding this comment.
That's a verb, all the other are nouns...
There was a problem hiding this comment.
resolve is already used to resolve kernel parameters in the env var
There was a problem hiding this comment.
Sorry, i meant "resolve" is also a verb.. legitimating to use "fetch" here.
There was a problem hiding this comment.
Right, of course... Should have seen that :) I think key is better as you are actually specifying the key you want to select from an array, while fetch can actually be to fetch right about anything.
d2ec983 to
42186a2
Compare
|
Thank you @bobvandevijver. |
…r (bobvandevijver) This PR was squashed before being merged into the 4.2-dev branch (closes #27157). Discussion ---------- [DI] Select specific key from an array resolved env var | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes <!-- don't forget to update src/**/CHANGELOG.md files --> | BC breaks? | no <!-- see https://symfony.com/bc --> | Deprecations? | no <!-- don't forget to update UPGRADE-*.md and src/**/CHANGELOG.md files --> | Tests pass? | yes <!-- please add some, will be required by reviewers --> | Fixed tickets | Discussed in #25643 <!-- #-prefixed issue number(s), if any --> | License | MIT | Doc PR | symfony/symfony-docs#9734 <!-- required for new features --> <!-- Write a short README entry for your feature/bugfix here (replace this comment block.) This will help people understand your PR and can be used as a start of the Doc PR. Additionally: - Bug fixes must be submitted against the lowest branch where they apply (lowest branches are regularly merged to upper ones so they get the fixes too). - Features and deprecations must be submitted against the master branch. --> As discussed in #25643, it would be convenient to have an key processor for environment variables which have been read from for example a JSON file. The main advantage of this feature lies in specifying a single file for your secrets, that can be directly used in your configuration, without leaking them into your env. ## Example **.secrets.json** ```json { "database_password": "xxx" } ``` **.env** ```env APP_SECRETS=/opt/application/.secrets.json DATABASE_URL=mysql://myuser:%database_password%@localhost:3306/mydb ``` **services.yaml** ```yaml parameters: database_password: '%env(key:database_password:json:file:APP_SECRETS)%' ``` This example configuration will result in a `database_password` parameter being filled with `xxx`, and due to Doctrine defaults, the database url will be resolved with the correct password. Commits ------- 42186a2 [DI] Select specific key from an array resolved env var
…guiluz) This PR was merged into the master branch. Discussion ---------- Added key env processor to docs Not much more to say, this is documenting the feature added in symfony/symfony#27157. Fixes #9734. Commits ------- 9c91cf1 Reworded and added other config formats 1d72bc2 Added key env processor to docs
As discussed in #25643, it would be convenient to have an key processor for environment variables which have been read from for example a JSON file.
The main advantage of this feature lies in specifying a single file for your secrets, that can be directly used in your configuration, without leaking them into your env.
Example
.secrets.json
{ "database_password": "xxx" }.env
services.yaml
This example configuration will result in a
database_passwordparameter being filled withxxx, and due to Doctrine defaults, the database url will be resolved with the correct password.