sf_debug var for flexibility in custom deployments

[wucdbm]

Q	A
Bug fix?	No
New feature?	Yes
BC breaks?	No
Deprecations?	No
Fixed tickets	N/A

sf_debug var to enable modifying whether --no-debug is appended to commands

[oanhnn]

I think this idea is good, but also other options arguments? What would you do with them?

[wucdbm]

I am not sure at this point, the day before yesterday was my first usage of this package and so far I'm loving it. This is just a little something I couldn't get done without modifying it or doing stuff by hand on the DEV server as I needed to deploy a clean copy there as well. The way I see it at this very moment, that's the only change I'd make.

Probably some function defined in the symfony.php scope (so also accessible in the main deployer.php file) such as

function runCommand($command) {
// $command = 'doctrine:migrations:migrate --env={{env}} '.trim(get('sf_debug')).' --no-interaction';
run('{{bin/php}} {{release_path}}/' . trim(get('bin_dir'), '/') . '/console '.$command);
}

or

function runCommand($command, $parameters = '') {
// --env={{env}} {{sf_debug}} // assuming sf_debug is moved as an env() variable always appended to any command automatically?
}

But I still have very little experience with it and since the recipe is already there, I just used it and it did the job besides the small thing with --no-debug dumping prod assets in the dev env even if I had set env and env_vars.

Other than that, I think configuring several servers that share the same directory structure and authentication would be nice, by means of simply passing an array of IPs to the host key in the yml config, but again, I don't have enough experience to know for sure what's best. Or maybe plan that for future versions? :)

Regards

[robfrawley]

See #688 which already purposed a fix for this, among other symfony-related issues.

[wucdbm]

#688 looks pretty nice to me at first glance, I'll close this

I'll reopen another one bout the servers thing at some point