How to make a Symfony application deploy

[jcornide]

Hi,

This is a great tool, although I'm having a lot of trouble to deploy a Symfony application with it and I don't know if I'm doing something wrong or I came across a bug.
I have set up everything and everything works fine (github connection, ssh connection with the server, etc).
The problem is when I deploy I get the following error:

> Sensio\Bundle\DistributionBundle\Composer\ScriptHandler::clearCache
PHP Fatal error:  Class 'Sensio\Bundle\GeneratorBundle\SensioGeneratorBundle' not found in /var/www/socialcar/releases/20151214162603/app/AppKernel.php on line 62

Fatal error: Class 'Sensio\Bundle\GeneratorBundle\SensioGeneratorBundle' not found in /var/www/socialcar/releases/20151214162603/app/AppKernel.php on line 62

This error occurs because the post update/install Symfony commands are being executed in development enviroment mode instead production mode.
To solve this I need to create a env var called SYMFONY_ENV with the value prod (see the info box here http://symfony.com/doc/current/cookbook/deployment/tools.html#c-install-update-your-vendors)
So I tried to create a before command for the composer step with this:

export SYMFONY_ENV=prod

But it doesn't work, I even tried to debug it adding this to the bash:

export SYMFONY_ENV=prod
echo "Symfony ENV is:" SYMFONY_ENV

And I don't get nothing, the SYMFONY_ENV is still blank.
Any idea on how to solve this or find a workaround?
P.S.: It would be great for debuggin purposes if you add the command that is being executed in the server in the console output modal window.
Again, great tool :)

[REBELinBLUE]

Ah yeah I have an issue open to allow variables to be set for exactly this reason, I knew it was required in symfony but didn't know exactly what for #108

The problem with creating a step is that it will only exist for that specific step, the environment for each command is independent of the others.

If .env has APP_DEBUG=true and APP_ENV=local it will actually output the commands in the server log

For now what you could do is edit https://github.com/REBELinBLUE/deployer/blob/master/app/Jobs/DeployProject.php#L353 and add

'export SYMFONY_ENV=prod' to the $commands array and I will try and get this feature sorted ASAP.

Alternatively, you could add it to the ~/.bash_profile file for the user you are deploying as

[REBELinBLUE]

Hmm, just re-read what you said, for the command where you've echoed it, wouldn't you need

export SYMFONY_ENV=prod echo "Symfony ENV is:" $SYMFONY_ENV

But, as I said, the variable wouldn't exist in the next command. I shall try and get the bug fixed by the end of the week, it shouldn't be a huge amount of work

[jcornide]

Hi,
Sorry, I missed the $ in the command, anyway it doesn't work as you said.
I tried adding the export in the bashrc, and this is getting way to weird. This is my bashrc:

export SYMFONY_ENV=prod
export

And when I log in with the same user and I use in the deployer I got this:

Last login: Mon Dec 14 11:07:26 2015 from 150.red-83-56-21.staticip.rima-tde.net
declare -x COMP_WORDBREAKS="
\"'><;|&(:"
declare -x HOME="/root"
declare -x LANG="en_US.UTF-8"
declare -x LOGNAME="root"
declare -x MAIL="/var/mail/root"
declare -x OLDPWD
declare -x PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"
declare -x PWD="/root"
declare -x SHELL="/bin/bash"
declare -x SHLVL="1"
declare -x SSH_CLIENT="83.------- 59537 22"
declare -x SSH_CONNECTION="83.----- 59537 46.101.190.170 22"
declare -x SSH_TTY="/dev/pts/2"
declare -x SYMFONY_ENV="prod"
declare -x TERM="xterm-256color"
declare -x USER="root"
declare -x XDG_RUNTIME_DIR="/run/user/0"
declare -x XDG_SESSION_ID="213"

As you can see the SYMFONY_ENV var is present. Well, still not working, so I added the command export before the composer update, and I get this:

declare -x HOME="/root"
declare -x LANG="en_US.UTF-8"
declare -x LOGNAME="root"
declare -x MAIL="/var/mail/root"
declare -x OLDPWD
declare -x PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games"
declare -x PWD="/root"
declare -x SHELL="/bin/bash"
declare -x SHLVL="2"
declare -x SSH_CLIENT="46.101.190.170 34868 22"
declare -x SSH_CONNECTION="46.101.190.170 34868 46.101.190.170 22"
declare -x USER="root"
declare -x XDG_RUNTIME_DIR="/run/user/0"
declare -x XDG_SESSION_ID="207"

The var is not present. Maybe it is because the deployer executes the command directly without starting a ssh session?

[REBELinBLUE]

Sorry for the delay, I am working on this now

[REBELinBLUE]

OK I figured out why using

export SYMFONY_ENV=prod echo "Symfony ENV is:" $SYMFONY_ENV

In a script doesn't work, because the $SYMFONY_ENV is being evaluated by the machine running deployer before it is sent to the remote server. Easy enough to fix

Now to figure out why the variables from ~/.bashrc aren't available

[REBELinBLUE]

if I add the following to ~/.bashrc

export FOO=bar

and then

echo $FOO

to the "Before Clone" script I get bar in the output.

Where in ~/.bashrc did you add export SYMFONY_ENV=prod? could you paste the whole file?

For example mine has

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
sac

right near the top, which means any export commands after it are not run, if I put them before they work.

[ -z "$PS1" ] && return

and

[[ $- != *i* ]] && return

look like they will do the same thing

[jcornide]

Hi Stephen,

Sorry for the delay. What file do you want me to paste? the before deploy?

On Wed, Dec 30, 2015 at 1:37 AM, Stephen Ball notifications@github.com
wrote:

if I add the following to ~/.bashrc

export FOO=bar

and then

echo $FOO

to the "Before Clone" script I get bar in the output.

Where in ~/.bashrc did you add export SYMFONY_ENV=prod? could you paste
the whole file?

—
Reply to this email directly or view it on GitHub
#133 (comment)
.

José Cornide
Tlf.: 609 720 220

[REBELinBLUE]

No problem, busy time of year for everyone. I was just wondering what was in your ~/.bashrc as it should pick up variables defined there

[jcornide]

~/.bashrc: executed by bash(1) for non-login shells.

see /usr/share/doc/bash/examples/startup-files (in the package bash-doc)

for examples

If not running interactively, don't do anything

[ -z "$PS1" ] && return

don't put duplicate lines in the history. See bash(1) for more options

... or force ignoredups and ignorespace

HISTCONTROL=ignoredups:ignorespace

append to the history file, don't overwrite it

shopt -s histappend

for setting history length see HISTSIZE and HISTFILESIZE in bash(1)

HISTSIZE=1000
HISTFILESIZE=2000

check the window size after each command and, if necessary,

update the values of LINES and COLUMNS.

shopt -s checkwinsize

make less more friendly for non-text input files, see lesspipe(1)

[ -x /usr/bin/lesspipe ] && eval "$(SHELL=/bin/sh lesspipe)"

set variable identifying the chroot you work in (used in the prompt below)

if [ -z "$debian_chroot" ] && [ -r /etc/debian_chroot ]; then
debian_chroot=$(cat /etc/debian_chroot)
fi

set a fancy prompt (non-color, unless we know we "want" color)

case "$TERM" in
xterm-color) color_prompt=yes;;
esac

uncomment for a colored prompt, if the terminal has the capability; turned

off by default to not distract the user: the focus in a terminal window

should be on the output of commands, not on the prompt

#force_color_prompt=yes

if [ -n "$force_color_prompt" ]; then
if [ -x /usr/bin/tput ] && tput setaf 1 >&/dev/null; then
# We have color support; assume it's compliant with Ecma-48
# (ISO/IEC-6429). (Lack of such support is extremely rare, and such
# a case would tend to support setf rather than setaf.)
color_prompt=yes
else
color_prompt=
fi
fi

if [ "$color_prompt" = yes ]; then
PS1='${debian_chroot:+($debian_chroot)}[\033[01;32m]\u@\h[\033[00m]:[\033[01;34m]\w[\033[00m]$
'
else
PS1='${debian_chroot:+($debian_chroot)}\u@\h:\w$ '
fi
unset color_prompt force_color_prompt

If this is an xterm set the title to user@host:dir

case "$TERM" in
xterm_|rxvt_)
PS1="[\e]0;${debian_chroot:+($debian_chroot)}\u@\h: \w\a]$PS1"
;;
*)
;;
sac

enable color support of ls and also add handy aliases

if [ -x /usr/bin/dircolors ]; then
test -r ~/.dircolors && eval "$(dircolors -b ~/.dircolors)" || eval
"$(dircolors -b)"
alias ls='ls --color=auto'
#alias dir='dir --color=auto'
#alias vdir='vdir --color=auto'

alias grep='grep --color=auto'
alias fgrep='fgrep --color=auto'
alias egrep='egrep --color=auto'

fi

some more ls aliases

alias ll='ls -alF'
alias la='ls -A'
alias l='ls -CF'

Alias definitions.

You may want to put all your additions into a separate file like

~/.bash_aliases, instead of adding them here directly.

See /usr/share/doc/bash-doc/examples in the bash-doc package.

if [ -f ~/.bash_aliases ]; then
. ~/.bash_aliases
fi

enable programmable completion features (you don't need to enable

this, if it's already enabled in /etc/bash.bashrc and /etc/profile

sources /etc/bash.bashrc).

#if [ -f /etc/bash_completion ] && ! shopt -oq posix; then

. /etc/bash_completion

#fi

On Thu, Dec 31, 2015 at 5:59 PM, Stephen Ball notifications@github.com
wrote:

No problem, busy time of year for everyone. I was just wondering what was
in your ~/.bashrc as it should pick up variables defined there

—
Reply to this email directly or view it on GitHub
#133 (comment)
.

José Cornide
Tlf.: 609 720 220

[REBELinBLUE]

Yeah so right at the top you have

# If not running interactively, don't do anything
[ -z "$PS1" ] && return

than mean if you added export SYMFONY_ENV=prod later in the file it will never be defined for deployer as deployer obviously uses a non-login, non-interactive shell.

So if you define it it above that line it should work. Although it doesn't matter as I have always finished the feature to allow variables to be defined in deployer

[REBELinBLUE]

I have addressed this in #141

Seems to be working fine for me, can you confirm? (if you aren't able to run development builds, which need gulp & bower don't worry)

[jcornide]

Hi, I'll try on the first week of january, hopefully :)
Thanks a lot!

On Thu, Dec 31, 2015 at 7:01 PM, Stephen Ball notifications@github.com
wrote:

I have addressed this in #141
#141

Seems to be working fine for me, can you confirm? (if you aren't able to
run development builds, which need gulp & bower don't worry)

—
Reply to this email directly or view it on GitHub
#133 (comment)
.

José Cornide
Tlf.: 609 720 220

[REBELinBLUE]

No worries, the option is on the commands tab

[jcornide]

hi, is in the master branch? i just updated the code but I don't the see the changes

[REBELinBLUE]

It is in the env_variables branch

[REBELinBLUE]

I have merged into master now