The only thing I saw wrong in your deploy.rb is the task link_images; those commands should be in a string and passed as the argument to a run command. Your not getting an error yet because it's not referenced by a callback.
Some shared hosts can mess with the ability to create symbolic links; if you login as the same user and try to create the same symbolic links manually does it work correctly? I've only used capistrano with ubuntu, and though I've experimented with gentoo it was a long while ago; maybe someone else can confirm they use cap with gentoo with no issues... Or not. What version of git is on the shared host; what version of git are you using on your workstation? Try set :deploy_via, :checkout Which is the simplest deploy strategy when using git. Just to see if it can manage getting through it without errors. On Dec 14, 2010, at 12:04 AM, horseshoe7 <[email protected]> wrote: > So we're using shared hosting, and they tell me their system is based > on Gentoo Linux. > > capistrano (2.5.19, 2.5.2) > capistrano-ext (1.2.1) > > and deploy.rb is > http://pastie.org/1375401 > > it's set up for multi-staging, but I put the production server stuff > in this pastie above. This problem occurred before I installed > capistrano-ext. > > anyway, the issue is that the scripts fail at different points, and > sometimes they don't fail at the same place twice. Often has to do > with creating symbolic links or wanting to copy files from pone place > to another because those items already exist, but I also get fail > conditions that a hash didn't match what it expected from Git, and > what else? I'm not sure right now. > > I was using deploy_via, :copy, but it's irrelevant - I get errors > with :remote_cache too, because it all comes down to file copying. > The more I think about it, maybe it's the server OS that isn't happy? > > Any help would be greatly appreciated. > > > > On Dec 14, 1:42 am, Donovan Bray <[email protected]> wrote: >> Post your deploy.rb what your experiencing isn't normal. >> >> What version of capistrano >> >> What os are you deploying to? >> >> On Dec 13, 2010, at 12:14 PM, horseshoe7 <[email protected]> wrote: >> >>> Hi Donovan, >>> yeah, sorry to bark at you. It's just been highly frustrating that >>> nobody has documented this issue, but then I realize that instead of >>> just looking for recipes online, writing my own tasks could be >>> quicker. >> >>> I was using :remote_cache, but got these problems there as well, >>> but :clear_release_path could do the trick in the end. I'll give it a >>> try. >> >>> To bring it back to my general question - is there no way to 'force' >>> things to get done? I suppose that would be at a bash command level, >>> like the rm -rf command will force things. What about ln -rf ? does >>> that work? >> >>> Thanks for your help! >> >>> On Dec 13, 9:07 pm, Donovan Bray <[email protected]> wrote: >>>> 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 >>> athttp://groups.google.com/group/capistrano?hl=en > > -- > * 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 -- * 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
