Actually, I think it may be tied to what Jamis posts here http://groups.google.com/group/capistrano/browse_thread/thread/6a82d5303bc0b0e6/c8d966bb1c9e30b0?lnk=gst&q=current_release#c8d966bb1c9e30b0
I will try that and report back whether or not the issue is resolved. On Feb 14, 10:32 pm, jmadtech <[email protected]> wrote: > 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
