-
-
Notifications
You must be signed in to change notification settings - Fork 504
PHPUnit: use a .env file #465
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
Conversation
ghost
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pull request passes validation.
|
Have you seen #408 and related issues?
👍 I've seen multiple dotenv components using this. E.g: |
|
|
||
| use Symfony\Component\Dotenv\Dotenv; | ||
|
|
||
| (new Dotenv())->load(__DIR__.'/../.env', __DIR__.'/../.env.test'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If an env var is specified in both, .env.test wins, right?
Also, if we do this for the test environment, people will ask for it for other environments too. And I think they're right - it would be simpler to have a file like this that will load from .env.{ENV} (if it exists) and to require that from index.php and console. console is especially important - we don't want someone to run a bin/console test with --env=test and have different environment variables than their tests.
Check out https://github.com/symfony/recipes/pull/408/files - where we working on something similar to this. We were also putting even some extra code into this central "bootstrap" file to fully remove the duplication between index.php, console (and now) the test bootstrap.
| @@ -0,0 +1,2 @@ | |||
| APP_ENV=test | |||
| APP_SECRET=s$cretf0rt3st | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any benefit to defining these? The APP_ENV will always already be set. Perhaps just leave it blank, but with a comment that overrides can go here?
|
I’m with totally for “copying” the behavior of Create React App for several reasons:
I’ll update the PR accordingly tomorrow |
|
Superseded by #466. |
…s dotenv behavior (dunglas) This PR was merged into the 4.2-dev branch. Discussion ---------- [DotEnv] Add a new loadForEnv() method mimicking Ruby's dotenv behavior | Q | A | ------------- | --- | Branch? | master | Bug fix? | no | New feature? | yes | 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 | helps for symfony/recipes#465, symfony/recipes#408 | License | MIT | Doc PR | todo This PR adds a new `loadForEnv()` method that mimics the behavior of [Create React App](https://github.com/facebook/create-react-app/blob/master/packages/react-scripts/template/README.md#what-other-env-files-can-be-used), [Rails' DotEnv](https://github.com/bkeepers/dotenv#what-other-env-files-can-i-use) and probably some other libs: `DotEnv::loadForEnv()` will load the following files, starting from the bottom. The first value set (or those already defined in the environment) take precedence: - `.env` - The Original® - `.env.dev`, `.env.test`, `.env.prod`... - Environment-specific settings. - `.env.local` - Local overrides. This file is loaded for all environments _except_ `test`. - `.env.dev.local`, `.env.test.local`, `.env.prod.local`... - Local overrides of environment-specific settings. The plan is to use this method in the default SF installation (symfony/recipes#466). Commits ------- 774a78c [DotEnv] Add a new loadForEnv() method mimicking Ruby's dotenv behavior
Having to modify both
.envand andphpunit.xml.distwhen adding an environment variable is tedious and error prone.Storing env vars in different formats (XML and
.env) also leads to weird bugs such as #317.With this PR, in test mode
.envand.env.testfiles are always loaded..env.testallows to override env vars for this env.Not related with this PR: I don't really understand why we need both
.envand.env.dist. As.envfile must not be used in production anyway, can't we have only a (versioned).envfile and get rid of the.distone?For people not using Docker/Vagrant/etc, we may allow to override the values of the
.envfile in a.env.localfile (that will not be versioned).Even if we want to keep the
.distfile, cannot we always load it along with.env? Then we'll be able to only use.envto override some vars (the secrets) instead of having to copy the full content in both. wdyt?