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

Closed
dspaeth opened this Issue Mar 13, 2013 · 13 comments

Projects

None yet

5 participants

@dspaeth
dspaeth commented Mar 13, 2013

Hi,

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
release.

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

regards
dieter

@moellenbeck

+1

@leehambley
Member

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?

@leehambley
Member
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 Apr 24, 2013
@dspaeth
dspaeth commented Apr 24, 2013

@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.

@leehambley
Member

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)

@dspaeth
dspaeth commented Apr 25, 2013

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

@leehambley
Member

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.

@leehambley
Member

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

@dspaeth
dspaeth commented Apr 25, 2013

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

before "deploy:update_code", "reset_latest_release"
@leehambley
Member

Yes, but take care - read the implementation, it appears at first glance
not to be safe to be called more than once.

Lee Hambley

http://lee.hambley.name/
+49 (0) 170 298 5667

On 25 April 2013 08:37, dspaeth notifications@github.com wrote:

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

before "deploy:update_code", "reset_latest_release"


Reply to this email directly or view it on GitHubhttps://github.com/capistrano/capistrano/issues/415#issuecomment-16990895
.

@tispratik

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

@rjharmon

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/git_ssh_wrapper.sh"
end
after 'finalize_update', 'setup_gitssh'
@dspaeth
dspaeth commented May 14, 2013

@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