Fetch :deploy_to from stage file

[feedmeastraycat]

In my deploy.rb I have set :deploy_to, '/var/www/my_app' but in my production.rb I have to have set :deploy_to, '/home/http/my_app/deploy'. Composer is downloaded and installed into /home/http/my_app/deploy/shared/ but when Capistrano tries to run it to install the vendor dir it fails because it looks for /var/www/my_app.

The only way to get around this is to move the correct set :deploy_to directly in the deploy.rb file. But now I have to change it manually each time I deploy to staging or dev.

Not sure if I have done something wrong though. :) I'm still quite new to Capistrano and my only Ruby knowledge is from Capistrano.

These are my composer settings in deploy.rb:

set :composer_install_flags, "--no-dev --no-interaction --optimize-autoloader --prefer-dist"
set :composer_roles, :all
set :composer_dump_autoload_flags, '--optimize'
set :composer_download_url, "https://getcomposer.org/installer"

SSHKit.config.command_map[:composer] = "#{shared_path.join("composer.phar")}"

[swalkinshaw]

Could be a Cap bug but try defining deploy_to in a lambda like this:

set :deploy_to, -> { '/var/www/my_app' }

Some workaround like the following may work as well:

# deploy.rb
if fetch(:stage) == 'production'
  set :deploy_to, '/home/http/my_app/deploy'
else
  set :deploy_to, '/var/www/my_app'
end

[feedmeastraycat]

Thanks for your input! The lambda thing didn't seem to help. The workaround would though. But I would rather have the config separate.

But you think that it could be an issue in SSHKit rather maybe? (I guess that makes more sense).

[swalkinshaw]

capistrano/capistrano#845
capistrano/capistrano#815

Seem related to deploy_to in stage files.

[swalkinshaw]

Oh one more thing to try is:

SSHKit.config.command_map[:composer] = "#{fetch(:shared_path).join("composer.phar")}"
# and maybe even (not sure if SSHKit supports the lambda usage)
SSHKit.config.command_map[:composer] = -> { "#{fetch(:shared_path).join("composer.phar")}" }

[feedmeastraycat]

SSHKit.config.command_map[:composer] = "#{fetch(:shared_path).join("composer.phar")}"

Results in NoMethodError: undefined methodjoin' for nil:NilClass`. The lambda thing didn't work either.

The weird thing I guess, to me, is that composer.phar is downloaded to the correct path. So having :deploy_to set in both deploy.rb and production.rb/staging.rb works for everything except when capistrano/composer tries to run composer.

I'm not 100% sure but I assume its that SSHKit line. It doesn't fetch the right :shared_path somehow.

[feedmeastraycat]

If I do:

warn "#{shared_path.join("composer.phar")}"

In a task in :deploy namespace after :starting for example. I get the correct path. So maybe SSHKit runs "to early" or something.

[swalkinshaw]

http://stackoverflow.com/questions/24650384/access-to-shared-path-in-deploy-rb Good to see you're not alone.

[swalkinshaw]

I guess you could try:

set :composer_path = -> { fetch(:shared_path).join('composer.phar') }
SSHKit.config.command_map[:composer] = composer_path

But not sure about that since you're supposed to use fetch but that doesn't seem to work in the command map.

[feedmeastraycat]

Ah. Yeah. I Googled it but didnt find that one. -1 Google skills. :)

I moved the command_map line into that task. Which worked. So my assumption maybe was correct. I guess that's an "ok" solution.

namespace :deploy do

    before :starting, :map_composer_command do
        on roles(:app) do |server|
            SSHKit.config.command_map[:composer] = "#{shared_path.join("composer.phar")}"
        end
    end

...

Not sure that is the "right" solution though :)

[feedmeastraycat]

I tried a couple of different other like your last example there. But none work.

My task solution works at least. Even though it doesn't feel like a 100% proper solution. :)

Thanks for your time though!

[davidlonjon]

anks feedmeastraycat for your solution. I had the same problem and got it working thanks to yours which is the best so far (at least for me :))

[gagarine]

The "task solution" is kind of ugly. And if you have more than one executable it's not very user friendly. Can we reopen this issue?

[webdevilopers]

👍 for a constant solution @gagarine @davidlonjon ! Please also see issue #43.

[webdevilopers]

Any news on this?