$ cap production debug_tar_roles
Host Obj: 10.223.132.247 DEBUG[aabe7db0] Running /usr/bin/env hostname on 10.223.132.247 DEBUG[aabe7db0] Command: /usr/bin/env hostname DEBUG[aabe7db0] localhost.localdomain DEBUG[aabe7db0] Finished in 0.184 seconds with exit status 0 (successful). DEBUG[4d67cb3d] Running /usr/bin/env uptime on 10.223.132.247 DEBUG[4d67cb3d] Command: /usr/bin/env uptime DEBUG[4d67cb3d] 09:44:43 up 140 days, 8:34, 2 users, load average: 0.00, 0.01, 0.05 DEBUG[4d67cb3d] Finished in 0.009 seconds with exit status 0 (successful). INFOlocalhost.localdomain: 09:44:43 up 140 days, 8:34, 2 users, load average: 0.00, 0.01, 0.05 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, <[email protected] <javascript:>> 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, <[email protected]> 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 <[email protected]> >>>>> 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, <[email protected] >>>>>>> <mailto:[email protected]>> 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-w >>>>>>> ith-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 [email protected] >>>>>>> <mailto:[email protected]>. >>>>>>> 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 [email protected] >>>>>>> <mailto:[email protected]>. >>>>>>> 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 [email protected]. >>>>>> 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 [email protected]. >>>> To view this discussion on the web, visit https://groups.google.com/d/ >>>> msgid/capistrano/81bf41a0-cd09-4568-869e-10fbda651ce6% >>>> 40googlegroups.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 [email protected] <javascript:>. >> 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 [email protected]. To view this discussion on the web, visit https://groups.google.com/d/msgid/capistrano/26691f14-e4c1-423c-9757-26160b1acedb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
