Instructions for setting SYMFONY_ENV on Heroku

[dzuelke]

Much smoother sailing with that step included :)

On a related note, I was going to add general advice on using SYMFONY_ENV, as it is currently very under-documented (just one aside mention at http://symfony.com/doc/current/cookbook/deployment/tools.html#c-update-your-vendors), but I wasn't sure where to do this. Maybe in cookbook/configuration/environments.rst and a few other places?

[dzuelke]

@stof / @fabpot, any thoughts?

[stof]

looks good to me

[dzuelke]

Wanna merge it? And where do you think general docs on that env var should go?

On 05.12.2014, at 11:34, Christophe Coevoet [email protected] wrote:

looks good to me

—
Reply to this email directly or view it on GitHub.

[stof]

Wanna merge it?

I'm not a member of the doc core team. I don't have merge rights on this repo

[javiereguiluz]

@dzuelke thanks for this nice improvement and for documenting the SYMFONY_ENV usage.

You are right about the necessity of documenting more these variables (there is an opened issue related to this: #4162). However, as this is a quick fix for Heroku, my proposal for doc managers (@weaverryan, @wouterj and @xabbuh) would be to merge this PR right away and keep #4162 open to discuss more about where and how to document these variables.

[dzuelke]

👍 @javiereguiluz

[xabbuh]

Our standard is to not use Oxford commas.

[dzuelke]

But this is a subordinate clause, not a list of items, no?

[xabbuh]

I'm actually not completely sure. Maybe our native speaker @weaverryan can make it clear.

[weaverryan]

@dzuelke what do you mean by:

you will ensure that your Symfony application runs the prod environment

I mean, does the user need to do something here? Or do we just mean, double-check that things are ok when you go to app.php locally, just to be sure first? I'm just not sure myself, so I want it to be clear for others :)

[weaverryan]

Bah, nevermind - now I see the next section... - let me read the rest

[xabbuh]

I only see some minor issues. Besides that 👍.

[dzuelke]

Is this ready for a merge, @weaverryan ?

[weaverryan]

Hey David!

Merged! Thanks for this - I really want the Heroku instructions to be rock solid :). I created a follow-up PR with some minor formatting things - see #4601.

We still have #4217 open, which has some Heroku-deploy issues and discussion. In particular, I'm personally still unclear how parameters.yml should be handled. As you see on that issue, you can use the env-map of the Incenteev/ParameterHandler, should that be the best way? And if so, wouldn't that mean I'm committing sensitive parameters to my composer.json? So then, should we be using config vars. If so, this still needs to be the article, with details on how that will play with Incenteev - I remember my friend Jon having issues with that.

Thanks!

[stof]

@weaverryan the env-map feature of Incenteev/ParameterHandler has been implemented precisely to be able to provide the parameters through heroku config vars to build the parameters.yml (which is still ignored in the git repo) (disclaimer: I'm deploying my Symfony app on Heroku since 2 years at work).

[dzuelke]

@weaverryan In env-map, you do e.g.

"database.url": "DATABASE_URL"

to read env var DATABASE_URL into the container parameter database.url.

[dzuelke]

Mind you that there is a caveat though with both this approach and a parameters.php that you import where you do $container->setParameter('database.url', getenv('DATABASE_URL'));: at build time, those containers get dumped/cached, and the cache contains the literal value of the environment variable.

However, it is possible for env vars to change, either because the user changes them (through heroku config:set), or because the system does it automatically (e.g. when moving databases to a different for durability reasons).

In that case, an empty Git push would have to be made to restore the app to working order. I started looking into generating a getenv('DATABASE_URL') into the dumped container for special syntax like %env:DATABASE_URL%, but it's not trivial - in particular, bundles are not aware of this. Meh meh.

[stof]

@dzuelke I'm planning to try writing a bundle hooking into the container to change some service arguments to be retrieved dynamically from the environment at runtime (with a fallback to the configured parameter), precisely to support the case of Heroku Postgres HA plans. I will give you some feedback in a few days after my experiments.

[dzuelke]

@stof My super crude approach to hack it in was this (the XmlDumper change is just so it won't crash, and it gets the var_export()ed value, which is wrong, but you get the idea): https://gist.github.com/dzuelke/8fbe0179a90bdca0007e

[stof]

your approach will be broken, because lots of strings can be callables.
Note that I started working on my approach to this issue (but for Symfony 2.6.2+ only, which means 2.6@dev for now because I need symfony/symfony#13013 to fix the extension point added in 2.6)

[dzuelke]

Yeah, could also check for __invoke() or similar, but the question remains what to do for XML and YAML dumpers?

[dzuelke]

Did you push your work somewhere publicly? :) I'm curious!

[stof]

@dzuelke not yet. It is still in progress. I will open-source it this evening hopefully, or in the coming days (depending of how much time it takes me to have the initial version working). Watch new repos appearing on https://github.com/Incenteev/

[stof]

@dzuelke here it is: https://github.com/Incenteev/DynamicParametersBundle
It requires to use 2.6.x-dev or 2.7.x-dev though (the fix I did in Symfony is not yet released, it will be in 2.6.2)