Skip to content


Subversion checkout URL

You can clone with
Download ZIP


latest_release initialisation wrong with multiple task calls and deploy as last #415

dspaeth opened this Issue · 13 comments

5 participants



I have some issues with latest_release. When I set a path in my deploy.rb
like this

  set :test_path, "#{latest_release}/tmp"

globaly, then after "deploy:finalize_update" latest_release points to the previous

This also happens when I call multiple tasks which use latest_release
and also call deploy as last task like this

cap development do_some_thing deploy.

I think in the last case is a real bug and happens with older versions of capistrano gem and also version 2.14.2



This is simply because latest_release is evaluated when you start cap, and not reevaluated when the deploy starts. Can you not more mything to a before hook?

set :test_path, lambda { "#{latest_release}/tmp" }

Will delay evaluation of test_path (and thus latest_release) until the first time you use it, as against evaluating to nil at startup time.

@leehambley leehambley closed this

@leehambley Sorry, mist your first comment . Yes your right, with a lambda I can delay my evaluation, but when i use

 cap first_task second_task production deploy

And first_task uses test_path, then latest_release is wrong in all deploy depentend tasks.

I think as an user I should not care what task's I chain. latest_release should always point to
the right folder.


cap first_task second_task production deploy

This is a problem with any make/rake/etc task tool, there's no really sane way to resolve it, except for you to make your own release variable, and not use our internal ones.

I wish I had a better answer for you, but I run into similar problems with make from time to time. One solution would be to calculate latest_release and not to cache the result, which is actually a reasonable workaround, and would spare a lot of confusion (it's a cheap–ish operation)


Isn't it possible to reset latest_release every time a new release folder is created? Or is this the wrong point in time?


Isn't it possible to reset latest_release every time a new release folder is created? Or is this the wrong point in time?

It might be, but that's a quite severe change to the code, you should simply call:

cap first_task; cap second_task; cap production deploy

as a workaround.


You can of course look at the reset! method, amongst others in the variables code:


Ok, i will give it a try. Maybe some thing like

before "deploy:update_code", "reset_latest_release"

Did the reset! work for you? Am facing the same issue.


We had a similar issue, where setting up the default environment too early was evaluating latest_release too early.

We solved it by deferring the setting to the earliest possible moment that latest_release could be correctly evaluated; it was soon enough for our purpose:

task :setup_gitssh do
  default_environment["GIT_SSH"] = "#{latest_release}/script/"
after 'finalize_update', 'setup_gitssh'

@tispratik sorry, i couldn't dry it until now. At the moment we life with the walk around cap task_1 ; cap task_2
and don't chain them together.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.