Hey all,
I'm having a strange problem that just surfaced recently. For some
reason, my deploy script isn't registering the new release version
until the script is done. The application is reflecting the new
version of code, but my cap_gun emails reflect the previous version as
the current one and any database migrations that I run (if I run a cap
deploy:migrations) go against the previous version as well.
A couple quick tech details:
I'm using Capistrano 2.5.13, Capistrano-ext 1.2.1 (for multi-stage)
and cap_gun (not sure the exact version).
To start the process off, I run a #>cap <stage> deploy -s
comment="testing version information"
It goes through its standard startup and triggers my callbacks for
before deploy:update (in my case, I have 3 custom steps to set a flag,
test for a comment and make sure my monit application is running).
It is important to note that I've created a task (:log_deploy) that
runs after each server-side task to log the activity, version
information and user performing the activities into a database on an
admin server.
So, right after the command that starts the monit daemon, the value of
#{current_release} is "/path/to/my/app/releases/20100215025740",
#{previous_release} is "/path/to/my/app/releases/20100215024506" and
#{release_path} is "/path/to/my/app/releases/20100215025835"... all of
which are correct.
The next step is the SVN checkout, which checks out the correct
version of my code and puts it into /path/to/my/app/releases/
20100215025835.
The deploy:finalize_update and deploy:update_code appear to use the
correct version path as well. After the deploy:update_code, I have 2
after callbacks, a custom deploy:symlink_configs and a custom task
that gets the actual SVN revision from the server.
After those all complete, deploy:symlink runs and links current to the
coorect release path (/path/to/my/app/releases/20100215025835).
The very next step is to do a custom deploy:restart and a subsequent
log_deploy of the action. Here is where things look a little funky.
For some reason, the value of #{current_release} is still "/path/to/my/
app/releases/20100215025740", #{previous_release} is still "/path/to/
my/app/releases/20100215024506" and #{release_path} is "/path/to/my/
app/releases/20100215025835".
>From here on out, everything still acts as if 20100215025740 is the
current release (from the deploy script perspective). If I log into
the application at this exact moment, it will display "20100215024506"
as the release being served.
Migrations show as running against /path/to/my/app/releases/
20100215025740, my deploy:cleanup says that there's no releases to
cleanup (even though I have it set to 5 and there's now 6 releases)
and my cap_gun email shows /path/to/my/app/releases/20100215025740 as
the current release.
What am I missing? I didn't think I had any way to affect the value
of current_release and previous_release... so what could suddenly be
causing this?
Sorry for the long explanation and thanks in advance for any help!
Justin
--
* You received this message because you are subscribed to the Google Groups
"Capistrano" group.
* To post to this group, send email to [email protected]
* To unsubscribe from this group, send email to
[email protected] For more options, visit this group at
http://groups.google.com/group/capistrano?hl=en
