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, <deadbeef...@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-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%20298%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.3020703%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%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 capistrano+unsubscr...@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/CAN_%2BVLV4UpTQ8Y3d0JHUZQTYeZUCqeghGg%2BBufkk396qqnx51A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
