Actually, "current_release" is correct. If you look at the definition
for current_release:
_cset(:current_release) { File.join(releases_path, releases.last) }
Which returns the path of the last release in the releases directory:
_cset(:releases) { capture("ls -xt #{releases_path}").split.reverse }
Now, it could be that you've got a before() hook somewhere that is
calling (directly or indirectly) the releases variable, before the new
release is uploaded. In that case, Capistrano is caching the
pre-new-code value. You could try something like this to make sure
you're getting the right version:
before("deploy:migrate") { reset! :releases }
Calling reset! forces Capistrano to forget the cached value, so that the
next query for the releases variable will go and fetch the directory
list again from the server.
- Jamis
On 2/12/09 1:32 PM, max wrote:
> Hello
>
> I've just noticed a problem when using deploy:migrations (capistrano
> 2.5.4).
>
> It appears that "db:migrate" is executed from the current release
> directory (previously deployed), instead of the latest release
> directory (current deployment).
>
> So latest migrations shipped with latest release are not executed !
>
>
> The problem occurs in migrate task (called by migrations task).
>
> The line 374 in capistrano-2.5.4/lib/recipes/deploy/deploy.rb :
> when :latest then current_release
> should be :
> when :latest then latest_release
>
> So directory of the latest release (just deployed) is used to run
> migrations.
>
>
> I hope I'm not missing something here, and that the google group is
> the right place to propose a patch...
>
> Thanks
>
> ++
>
> Max
>
> >
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---
