local repositories no longer supported, why?

[Cathal O'Riordan]

Why are local git repositories no longer supported? v2 had good support for this, and it appears to be removed. Why is that?

Cathal.

Versions:

• Ruby
• Capistrano v3
• Rake / Rails / etc

Platform:

• Working on....
• Deploying to...

Logs:

• Please past logs (as completely as possible to a 3rd party pasting service such as pastie.org)

Files:

• Capfile
• deploy.rb
• Stage files (production.rb, staging.rb)

[Lee Hambley]

Why are local git repositories no longer supported? v2 had good support for this, and it appears to be removed. Why is that?

Local to which side? You mean self hosted? (i.e you are deploying to your Git host) If so, simply use a file:// Git URL.

Lee Hambley

--

http://lee.hambley.name/

+49 (0) 170 298 5667

--
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/48fb75d1-991d-4599-9900-3c6336fae67a%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Cathal O'Riordan]

That' right, self hosted.

Which parameter should be set to the local repo?

:repo_url, :repository, :local_repository

thanks,

Cathal.

[Lee Hambley]

Which parameter should be set to the local repo?

:repo_url, :repository, :local_repository

It should be repo_url, the others don't exist in Capistrano 3.​​

[Cathal O'Riordan]

I've set it like this:

set :scm, :git
set :repo_url, 'file:///Users/Cathal/Work/vle/moodle_24'

which when run as a deployment, results in 

fatal: '/Users/Cathal/Work/vle/moodle_24' does not appear to be a git repository

It looks like Capistrano is trying to run git ls-remote /Users/Cathal/Work/vle/moodle_24 on the deployment target. That's not right, is it?

Cathal.

[Lee Hambley]

You can't deploy from a repository on your machine, on your server yes.

Sent from my Nexus 4.

--

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/2969354b-6d15-4b32-a69e-4aa6f410fb72%40googlegroups.com.

[Cathal O'Riordan]

Why was that functionality removed?

[Lee Hambley]

It wasn't. That's never been possible without using the `copy` strategy which made a tarball of the current working directory, and uploaded it.

Lee Hambley

--

http://lee.hambley.name/

+49 (0) 170 298 5667

To view this discussion on the web, visit https://groups.google.com/d/msgid/capistrano/9e810460-66fd-451b-b27b-c51534f651a1%40googlegroups.com.

[Cathal O'Riordan]

And can you still use the copy strategy? 

[Lee Hambley]

There is no copy strategy, but you can undefined the "Git" tasks and https://github.com/capistrano/sshkit/blob/master/EXAMPLES.md#upload-a-directory-of-files or http://lee.hambley.name/2013/06/11/using-capistrano-v3-with-chef.html 

Capistrano will soon default to not loading the "Git" tasks at all, unless asked. (so you don't have to turn off features that you don't need, just don't load them in the first place.) There'll be an issue created soon enough, I thought there was one, but searching suggests not.

The copy strategy was removed due to nobody in the entire project's history ever having been satisfied with the default options we chose. (I might be exaggerating, but the feature never seemed to work out of the box for anyone, rsync, exclude patterns, sftp vs. scp, etc, etc, etc) - the easiest way is just to provide the versioning framework and give people the tools to do whatever works for them.

A bit reason for the move to backing Capistrano with Rake (see my blog link above) was to enable this conditional rebuild of binaries (tarballs, etc) for the use-cases such as deploying chef recipes, and things which don't necessarily need to be committed first, before you can test them (at least in all my experience, if I had to commit chef cookbooks before testing them, my Git history would be a mess.)

Hope that clarifies some of the "why" in the meantime, track this thread, I'll update it when I find, or create the ticket which is of interest to you.

Lee Hambley

--

http://lee.hambley.name/

+49 (0) 170 298 5667

To view this discussion on the web, visit https://groups.google.com/d/msgid/capistrano/ffb69e13-f25c-41fd-b004-e5f6774525cf%40googlegroups.com.

[Lee Hambley]

Follow-Up: 929: Do not load SCM tasks unless an SCM is defined

[Benjamin B]

The copy strategy was removed due to nobody in the entire project's history ever having been satisfied with the default options we chose. (I might be exaggerating, but the feature never seemed to work out of the box for anyone, rsync, exclude patterns, sftp vs. scp, etc, etc, etc) - the easiest way is just to provide the versioning framework and give people the tools to do whatever works for them.

Hi Lee,

I believe a lot of people was extremely satisfied, but you know how it goes: we never hear from satisfied people :)
The feature worked well out of the box for me for example. I have a local SVN server in my office, and could deploy flawlessly through the copy strategy.
Is it not a standard set-up to maintain his own repository server anymore?

At least if capistrano does not maintain the copy strategy anymore, can you route us to an alternative solution?

Thanks for the great work!

Regards,
Benjamin

[Lee Hambley]

Is it not a standard set-up to maintain his own repository server anymore?

I can't speak for everyone, but I don't consider a server in the office to be a server, unless it has backups, real DNS, and is accessible from everywhere. Also SVN is so hopelessly antiquated that I personally haven't used it in more than 5 years, so I can't even say what the paid hosting options are these days.

I know that a "copy" strategy is considered missing, I've been as clear as I can about why it's gone (to make a long story short, again, it was s foot gun, and often deployed secret files out of working copies, and with he myriad of options (scp, sftp, rsync, cp, etc, etc) it didn't work out of the box, and there was no "correct' way​ to copy a working copy to a production server.​

As documented on my blog, http://lee.hambley.name/2013/06/11/using-capistrano-v3-with-chef.html you can create a tarball with rake, and upload it to your server that way. It's not perfect, I know, but it's the closest I have ever documented to how you might do that.

Lee Hambley

--

http://lee.hambley.name/

+49 (0) 170 298 5667

--
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/4420c778-4142-46b1-9a98-4d0719cbfbd0%40googlegroups.com.

[Benjamin B]

On Wednesday, February 26, 2014 3:14:53 PM UTC+8, Lee Hambley wrote:

Is it not a standard set-up to maintain his own repository server anymore?

I can't speak for everyone, but I don't consider a server in the office to be a server, unless it has backups, real DNS, and is accessible from everywhere. Also SVN is so hopelessly antiquated that I personally haven't used it in more than 5 years, so I can't even say what the paid hosting options are these days.

Ok I understand that you made your choices concerning Capistrano. I ended-up creating my own copy strategy. It was quite simple, and the re-coding of Capistrano v3 is great simple and flexible. Congratulations!

A little think I just want to clarify, because this is a public accessible discussion and a non-experimented person could mistakenly take your consideration for the truth:
- The definition of a 'server' is not related to his connectivity to internet, or to the kind of service it serve.
- SVN is very actual, and no better not worse and other products