Alright, from the output you can see that for some reason (and I don't see why in your code that you posted) that the command is being run *twice*. This means somewhere you have the same IP address being setup twice, maybe in Capfile, and your production.rb, or something? Search for it, and make sure it only happens once.
If you have the Gemfile with those contentns: $ gem install bundler $ bundle install $ bundle exec cap whatever:task:you:want:to:execute This allows you to use pre-release versions of gems, etc, it will also generate a Gemfile.lock, which you may or may not to choose to commit into your SCM and then encourage your colleagues to use Bundler, then they don't get bitten if we release a new (incompatible) version of Cap in the future, since bundler will always take the version in the .lock file. Lee Hambley http://lee.hambley.name/ +49 (0) 170 298 5667 On 20 February 2015 at 17:03, <deadbeef...@gmail.com> wrote: > I'm still reading about Gemfile and how I use it, etc., like I said no > ruby experience what so ever and the app is not a ruby app. I got the > Gemfile created and put in the lines you suggested, but trying to figure > out where to go from there. > > > > On Thursday, February 19, 2015 at 2:53:06 PM UTC-6, Lee Hambley wrote: >> >> Alright, so I looked into that - I'd suggest a couple of thins, first of >> all take Capistrano and SSHKit from Master, if you don't have a Gemfile, >> you might need to read this, http://bundler.io/v1.3/gemfile.html if you >> do have a Gemfile, change the `gem "capistrano"` line to something like >> this: >> >> gem "capistrano", github: "capistrano/capistrano" >> gem "sshkit", github: "capistrano/sshkit" >> >> This will get the latest bleeding edge pre-release versions, which are >> scheduled for release soon (read: when I get half a day to write the >> changelogs, and do some final testing) >> >> Otherwise, since you only *have* one server that I can see defined here, >> I can't imagine what is going wrong. >> >> roles(:all) is a special case which should match any server defined with >> either role() or server(), on #294 you can see that the copy.rake is >> checking to see if you specified a special role name for `tar_roles` (you >> didn't), the 2nd argument to fetch is the default, :all… so you should be >> in good hands so far. >> >> I'd suggest the following, add and run this, and let me see the output: >> >> task :debug_tar_roles do >> on roles(fetch(:tar_roles, :all)) do |h| >> puts "Host Obj: #{h}" >> info "#{capture(:hostname)}: #{capture(:uptime)}" >> end >> end >> >> This should distil the issue here, which is `roles()` all doesn't seem to >> be doing what we think… beyond that, come back, share the log, and in the >> meantime i'll pick more thoroughly through your pastie/original log. >> (knowing now that you only have one server) >> >> >> Lee Hambley >> http://lee.hambley.name/ >> +49 (0) 170 298 5667 >> >> On 19 February 2015 at 21:29, <deadb...@gmail.com> wrote: >> >>> Thank you Lee. See http://pastie.org/9963632 >>> >>> I've included the copy.rake file too, just in case you need it. >>> >>> >>> >>> On Thursday, February 19, 2015 at 2:11:23 PM UTC-6, Lee Hambley wrote: >>>> >>>> Alright, so sounds like you need Capistrano after all. (Welcome back >>>> ;-)) so the obvious next step would be for you to share (ideally a Github >>>> gist, or pastie, or something *not* inline in the email) your >>>> configuration. We'll need your Capfile, deploy.rb, and your stage >>>> (./config/deploy/________.rb) file to figure out what's not working. I >>>> understand your need for privacy, but if you butcher too much of the host >>>> config you might butcher out the detail that we need to diagnose the issue. >>>> If you prefer feel free to mail that stuff to Jonathan and I off-list, and >>>> whatever the solution, we can post a follow up to the list maintaining your >>>> privacy once we diagnose the issue. >>>> >>>> You will need the no-scm plugin, we just have to look a little harder >>>> to find out why it's not working. >>>> >>>> Lee Hambley >>>> http://lee.hambley.name/ >>>> +49 (0) 170 298 5667 >>>> >>>> On 19 February 2015 at 19:43, <deadb...@gmail.com> wrote: >>>> >>>>> The system that is in place now uses cap (v2) and uses rollbacks and >>>>> simply copies the contents of . to |host|. I found when I tried that same >>>>> setup with cap (v3), it broke as cap now requires the use of a SCM which >>>>> was never used in the current setup. >>>>> >>>>> I tried that plugin to add functionality to cap, that is the ability >>>>> to simply upload <something> to |host| instead of using git. I was hoping >>>>> that cap would then continue on with creating releases, symlinks, >>>>> rollbacks, etc.. When I read the blog post you wrote, I removed the plugin >>>>> and tried again, using native cap without extras and ran into the problem >>>>> of cap requiring SCM. >>>>> >>>>> If I understand what you wrote correctly below, cap must have an SCM. >>>>> Which I believe is different from cap 2, correct? >>>>> >>>>> The plugin does upload the archive.tar.gz file, but it appears to be >>>>> doing it twice. The file is uploaded and expanded in >>>>> .../releases/2015.../ >>>>> as it should be. (See log on previous post.) In its .rake file I see >>>>> >>>>> on roles(tar_roles) do >>>>> >>>>> # Make sure the release directory exists >>>>> >>>>> puts "==> release_path: #{release_path} is created on >>>>> #{tar_roles} roles <==" >>>>> >>>>> The last lines output is shown twice when I run a simple cap deploy, >>>>> which I don't understand. In this simple test setup, there is only a >>>>> single >>>>> target so not sure why 2x. I don't know if the problem lies with the >>>>> plugin or cap or my config/deploy.rb file. >>>>> >>>>> I maybe off but it looks like the copy action is being called twice. >>>>> Which I suspect has something to do with tasks and dependencies, but since >>>>> I don't understand cap much I could be off (and I know even less about >>>>> ruby, other than I seriously dislike its syntax as it is not like anything >>>>> I'm used to using. :) ) >>>>> >>>>> The apps being deployed are not ruby apps. The |host| targets do not >>>>> have access to the repo (which isn't git/svn/hg anyway). The machine where >>>>> cap is run from does have access to the "repo" and copies the files >>>>> locally, and then the files can be uploaded to the targets. >>>>> >>>>> Given the scenario I'm dealing with, what do the capistrano experts >>>>> advise? I could even live with a modified version of rollbacks where >>>>> backup tarballs are kept on the host where cap runs from. Thinking that if >>>>> I have to use Rake+SSHKit, then maybe the way to go would be create a task >>>>> that creates a local tarball as a backup first. >>>>> >>>>> Thank you, >>>>> -deadbeef >>>>> >>>>> >>>>> >>>>> On Thursday, February 19, 2015 at 11:27:57 AM UTC-6, Lee Hambley wrote: >>>>>> >>>>>> Well, that might be true, but in this case I think it's a justified >>>>>> statement :) As I understood it, he's trying to use a plugin I'm not >>>>>> familiar with to remove functionality he doesn't need from Cap, usually >>>>>> "cap does more than I want" means I ought to drop down and use >>>>>> Rake+SSHKit. >>>>>> (Although, admittedly, until we get around to *actually* making the SCM >>>>>> optional, there may be valid, mature workflows which mandate the lack of >>>>>> an >>>>>> SCM, and require rollbacks, bundler, rvm, etc) I don't think that's the >>>>>> case here though. And, if it is, I can't help him since I don't know what >>>>>> the no-scm plugin is doing wrong in this case (seems like not even >>>>>> uploading the tarball from what I can see) >>>>>> >>>>>> Lee Hambley >>>>>> http://lee.hambley.name/ >>>>>> +49 (0) 170 298 5667 >>>>>> >>>>>> On 19 February 2015 at 18:24, Jonathan Rochkind <roch...@jhu.edu> >>>>>> wrote: >>>>>> >>>>>>> Even if you're doing tarball uploads, mightn't you still want >>>>>>> rollbacks, migrations, changelogs, etc? I understand that Cap might not >>>>>>> support that, but it's not obvious to me that it would be 'wasted' if it >>>>>>> did! >>>>>>> >>>>>>> On 2/19/15 12:22 PM, Lee Hambley wrote: >>>>>>> >>>>>>>> The post I linked replaces Cap, since if you're not using an SCM you >>>>>>>> lose most of the benefit of Cap. If you need a list of files >>>>>>>> throwing >>>>>>>> into a tarball and uploading, on more than one machine then you >>>>>>>> need to >>>>>>>> look at Rake+SSHKit which are two thirds of Capistrano, but >>>>>>>> Capistrano >>>>>>>> specifically adds rollbacks, plugins for Ruby, Rails, Migrations, >>>>>>>> changelogs/etc, it's all wasted on you if you're just doing tarball >>>>>>>> uploads though. >>>>>>>> >>>>>>>> Lee Hambley >>>>>>>> http://lee.hambley.name/ >>>>>>>> +49 (0) 170 298 5667 >>>>>>>> >>>>>>>> On 19 February 2015 at 18:01, <deadb...@gmail.com >>>>>>>> <mailto:deadb...@gmail.com>> wrote: >>>>>>>> >>>>>>>> I've read your posting and it is making some sense. If using >>>>>>>> the >>>>>>>> file/FileList task, what value should :scm be set to such that a >>>>>>>> 'cap deploy' does not try to run git? >>>>>>>> >>>>>>>> -deadbeef >>>>>>>> >>>>>>>> On Thursday, February 19, 2015 at 6:31:45 AM UTC-6, Lee Hambley >>>>>>>> wrote: >>>>>>>> >>>>>>>> Everyone always overengineers this, look at this blog post I >>>>>>>> wrote which does exactly what you need: >>>>>>>> http://lee.hambley.name/__2013/06/11/using-capistrano-__v3- >>>>>>>> with-chef.html >>>>>>>> <http://lee.hambley.name/2013/06/11/using-capistrano-v3- >>>>>>>> with-chef.html> >>>>>>>> Fewer tools, less code, easier to follow. And 100% less >>>>>>>> plugins >>>>>>>> and magic. >>>>>>>> >>>>>>>> Lee Hambley >>>>>>>> http://lee.hambley.name/ >>>>>>>> +49 (0) 170 298 5667 <tel:%2B49%20%280%29%20170%202 >>>>>>>> 98%205667> >>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the >>>>>>>> Google >>>>>>>> Groups "Capistrano" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from >>>>>>>> it, >>>>>>>> send an email to capistrano+...@googlegroups.com >>>>>>>> <mailto:capistrano+unsubscr...@googlegroups.com>. >>>>>>>> To view this discussion on the web, visit >>>>>>>> https://groups.google.com/d/msgid/capistrano/647a1381-7cef-4 >>>>>>>> 39a-8685-1ea1e71589c4%40googlegroups.com >>>>>>>> <https://groups.google.com/d/msgid/capistrano/647a1381-7cef- >>>>>>>> 439a-8685-1ea1e71589c4%40googlegroups.com?utm_medium=email&u >>>>>>>> tm_source=footer>. >>>>>>>> >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "Capistrano" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send >>>>>>>> an email to capistrano+...@googlegroups.com >>>>>>>> <mailto:capistrano+unsubscr...@googlegroups.com>. >>>>>>>> To view this discussion on the web, visit >>>>>>>> https://groups.google.com/d/msgid/capistrano/CAN_%2BVLUyQskk >>>>>>>> LRO9FRkwo0iYEiERREoCL6EEqwAjk2D17thH7g%40mail.gmail.com >>>>>>>> <https://groups.google.com/d/msgid/capistrano/CAN_%2BVLUyQsk >>>>>>>> kLRO9FRkwo0iYEiERREoCL6EEqwAjk2D17thH7g%40mail.gmail.com?utm >>>>>>>> _medium=email&utm_source=footer>. >>>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Capistrano" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to capistrano+...@googlegroups.com. >>>>>>> To view this discussion on the web, visit >>>>>>> https://groups.google.com/d/msgid/capistrano/54E61C49.302070 >>>>>>> 3%40jhu.edu. >>>>>>> >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Capistrano" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to capistrano+...@googlegroups.com. >>>>> To view this discussion on the web, visit https://groups.google.com/d/ >>>>> msgid/capistrano/81bf41a0-cd09-4568-869e-10fbda651ce6%40googl >>>>> egroups.com >>>>> <https://groups.google.com/d/msgid/capistrano/81bf41a0-cd09-4568-869e-10fbda651ce6%40googlegroups.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Capistrano" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to capistrano+...@googlegroups.com. >>> To view this discussion on the web, visit https://groups.google.com/d/ >>> msgid/capistrano/d0527002-a2e5-4696-b5a0-2d55c27dddab%40googlegroups.com >>> <https://groups.google.com/d/msgid/capistrano/d0527002-a2e5-4696-b5a0-2d55c27dddab%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "Capistrano" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to capistrano+unsubscr...@googlegroups.com. > To view this discussion on the web, visit > https://groups.google.com/d/msgid/capistrano/321e1b7d-d393-455a-81dd-1cae8f55f36b%40googlegroups.com > <https://groups.google.com/d/msgid/capistrano/321e1b7d-d393-455a-81dd-1cae8f55f36b%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Capistrano" group. To unsubscribe from this group and stop receiving emails from it, send an email to capistrano+unsubscr...@googlegroups.com. To view this discussion on the web, visit https://groups.google.com/d/msgid/capistrano/CAN_%2BVLVCNy9f4mytowvON5ovps74ugY-J6Nt5F2RHG9ovNOXqg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
