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 
> <javascript:>> 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 <javascript:>
>>> <mailto:deadb...@gmail.com <javascript:>>> 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%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 <javascript:>
>>>     <mailto:capistrano+unsubscr...@googlegroups.com <javascript:>>.
>>>     To view this discussion on the web, visit
>>>     https://groups.google.com/d/msgid/capistrano/647a1381-
>>> 7cef-439a-8685-1ea1e71589c4%40googlegroups.com
>>>     <https://groups.google.com/d/msgid/capistrano/647a1381-
>>> 7cef-439a-8685-1ea1e71589c4%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 <javascript:>
>>> <mailto:capistrano+unsubscr...@googlegroups.com <javascript:>>.
>>> To view this discussion on the web, visit
>>> https://groups.google.com/d/msgid/capistrano/CAN_%
>>> 2BVLUyQskkLRO9FRkwo0iYEiERREoCL6EEqwAjk2D17thH7g%40mail.gmail.com
>>> <https://groups.google.com/d/msgid/capistrano/CAN_%
>>> 2BVLUyQskkLRO9FRkwo0iYEiERREoCL6EEqwAjk2D17thH7g%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 <javascript:>.
>> 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+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/capistrano/81bf41a0-cd09-4568-869e-10fbda651ce6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to