You were asking for help for some bizarre behavior, and you were skipping a
step, I'm not a mind reader I could only infer as much as you wrote. It
seemed to me natural to verify you had followed a normal progression to get
where you got yourself.
Without looking at your code we can't predict all of the custom before and
after callbacks that may change by calling update_code directly ie: possibly
missing any callbacks you yourself have done for deploy. I was simply making
sure you were correctly using capistrano. Jumping directly to update_code is
abnormal.
I don't use the :copy strategy, I have a feeling that might be where the
problem most likely lies.
I use the :remote_cache strategy for all of my deployments, but I still run
into what you describe because I overwrite how Capistrano generates the
release path, so I use this task to make sure the directory doesn't exist
when I do a full deploy.
before "deploy:update_code", "deploy:clear_release_path"
namespace :deploy do
desc "Clear the release_path for a new checkout"
task :clear_release_path, :roles=>[:app] do
run "rm -rf #{release_path}"
end
end
Try the above, or try a different strategy.
Consider posting your deploy.rb as a gist, or other snippit posting service.
On Mon, Dec 13, 2010 at 9:34 AM, horseshoe7 <[email protected]> wrote:
> obviously. but deploy:update_code is a sub-task of deploy, so if it
> doesn't work, neither will deploy
>
> I don't mean to be rude, but it's pretty much safe to assume that all
> users of capistrano would have tried deploy:setup and then deploy, so
> perhaps you're trying to help, but I wouldn't have spent hours trying
> to figure this out if that were the solution. it's in every
> introductory document.
>
>
>
>
--
* 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
