[Capistrano] Re: Limit the list of servers when running a remote command

2007-01-23 Thread Jamis Buck
Environment variables can be set as you described when using "run". Unfortunately, it's trickier when using sudo. :( For now, the easiest way to do it with sudo is to create a shell script that sets the environment and runs the commands, and invoke that script via sudo. You can always do:

[Capistrano] Re: Cap ShellScriptBuilder

2007-01-23 Thread S. Robert James
On Jan 23, 9:49 am, "Rob Sanheim" <[EMAIL PROTECTED]> wrote: >Agreed, going with the underscore approach is asking for pain in the > long run, IMHO. There are just too many ambiguous cases that will > come up. Another advantage of having it as a param is that it makes it easy to pass. Case in

[Capistrano] Re: Limit the list of servers when running a remote command

2007-01-23 Thread Mathieu Lajugie
It works great, thanks! I guess I should have looked at the changelog first... Is there also a way to set environment variables before running a command, like PATH? It is ok to do: run "PATH=/my/path/to/bin:$PATH env | grep PATH" But doing the same with sudo fails because: sudo "PATH=/my/pa

[Capistrano] Re: Cap ShellScriptBuilder

2007-01-23 Thread S. Robert James
The biggest thing I miss in shell scripts over Ruby is exceptions. I like my apps to crash quickly if something goes wrong (unless I explicitly rescue it), rather than try to continue blindly like shell scripts do by default. Worst case example: cd /dir/with/a/typo rm -rf # don't try this at ho

[Capistrano] Re: Progress!

2007-01-23 Thread S. Robert James
Jamis Buck wrote: > On Jan 23, 2007, at 2:42 PM, S. Robert James wrote: > > > > > I would suggest to versions of cached_repository: > > > > 1. Incremental. > > 2. Clean (rm -rf and sync everything from the beginning). > > Could you elaborate on the difference between these? Sure. #1 asks the SC

[Capistrano] Re: Progress!

2007-01-23 Thread Jacob Atzen
On Tue, Jan 23, 2007 at 03:16:22PM -0700, Jamis Buck wrote: > > On Jan 23, 2007, at 3:11 PM, Jacob Atzen wrote: > > > > > On Tue, Jan 23, 2007 at 01:54:36PM -0700, Jamis Buck wrote: > >>> Might I suggest a combination of cached_repository and copy_*? > >>> Perhaps > >>> implemented over rsync?

[Capistrano] Re: Progress!

2007-01-23 Thread Jamis Buck
On Jan 23, 2007, at 3:11 PM, Jacob Atzen wrote: > > On Tue, Jan 23, 2007 at 01:54:36PM -0700, Jamis Buck wrote: >>> Might I suggest a combination of cached_repository and copy_*? >>> Perhaps >>> implemented over rsync? >>> >>> Something along the lines of: >>> - Checkout / export into local cop

[Capistrano] Re: Progress!

2007-01-23 Thread Jacob Atzen
On Tue, Jan 23, 2007 at 01:54:36PM -0700, Jamis Buck wrote: > > Might I suggest a combination of cached_repository and copy_*? Perhaps > > implemented over rsync? > > > > Something along the lines of: > > - Checkout / export into local copy - to avoid having remote repos > > access > > - Rsync l

[Capistrano] Re: bugfix and new feature

2007-01-23 Thread Jamis Buck
On Jan 23, 2007, at 2:47 PM, S. Robert James wrote: > Jamis Buck wrote: >> My vision for Capistrano 2.0 is to follow the suggestions a few >> people have offered and decouple "Capistrano-the-part-that-executes- >> remote-processes" from "Capistrano-does-rails-deployment". The "core" >> capistrano

[Capistrano] Re: Progress!

2007-01-23 Thread Jamis Buck
On Jan 23, 2007, at 2:42 PM, S. Robert James wrote: > > I would suggest to versions of cached_repository: > > 1. Incremental. > 2. Clean (rm -rf and sync everything from the beginning). Could you elaborate on the difference between these? > > (On Perforce, this would be p4 sync and rm -rf && p4

[Capistrano] Re: bugfix and new feature

2007-01-23 Thread S. Robert James
Jamis Buck wrote: > My vision for Capistrano 2.0 is to follow the suggestions a few > people have offered and decouple "Capistrano-the-part-that-executes- > remote-processes" from "Capistrano-does-rails-deployment". The "core" > capistrano bit would be installable standalone, with no defaults. Th

[Capistrano] Re: Progress!

2007-01-23 Thread S. Robert James
I would suggest to versions of cached_repository: 1. Incremental. 2. Clean (rm -rf and sync everything from the beginning). (On Perforce, this would be p4 sync and rm -rf && p4 sync -f) Many continuos integration systems let you choose between these two. Also, might it be possible to have a ho

[Capistrano] Re: Progress!

2007-01-23 Thread rylin
Jacob Atzen wrote: > Does this sound like a good idea to anyone but me? > Yeah ;-) Having caches here and there definitely helps when you have huge geographical distribution. We've got servers in some 30+ countries by my latest count; some on islands with very limited bandwidth. The best thing w

[Capistrano] Re: Progress!

2007-01-23 Thread Jamis Buck
On Jan 23, 2007, at 1:20 PM, Jacob Atzen wrote: > On Tue, Jan 23, 2007 at 11:35:31AM -0700, Jamis Buck wrote: >> >> I've got a plugin working which decouples deployment from the SCM in >> use. It currently supports only Subversion (I'll be emailing the >> maintainers of the other Capistrano SCM m

[Capistrano] Re: Multiple dirs from one repo?

2007-01-23 Thread rylin
Wow, thanks - that looks perfect! While I did work out a pretty good way of doing it The Hard Way(tm), Externals looks to be the much preferrable solution - I knew I couldn't be the only one with this kind of "problem" ;-) Cheers, / o Randall Potter wrote: > If your using svn you can use svn:ex

[Capistrano] Re: Limit the list of servers when running a remote command

2007-01-23 Thread Jamis Buck
mathieul, You can actually do this: task :my_test, :hosts => "linux7" do ... end That will then execute that task _specifically_ and _only_ on the linux7 host. Does that work for you? - Jamis On Jan 23, 2007, at 12:18 PM, mathieul wrote: > > Hello, > > I'm pretty new to using Ca

[Capistrano] Re: Progress!

2007-01-23 Thread Jacob Atzen
On Tue, Jan 23, 2007 at 11:35:31AM -0700, Jamis Buck wrote: > > I've got a plugin working which decouples deployment from the SCM in > use. It currently supports only Subversion (I'll be emailing the > maintainers of the other Capistrano SCM modules to work with them on > that), but it supp

[Capistrano] Limit the list of servers when running a remote command

2007-01-23 Thread mathieul
Hello, I'm pretty new to using Capistrano (but pretty addicted already) so I apologize in advance if this topic has been answered many times already. I am trying to get our company to start using Ruby. One of the components I am trying to replace is cfengine. I think that Capistrano would be muc

[Capistrano] Progress!

2007-01-23 Thread Jamis Buck
I've got a plugin working which decouples deployment from the SCM in use. It currently supports only Subversion (I'll be emailing the maintainers of the other Capistrano SCM modules to work with them on that), but it supports FIVE different deployment strategies (well, only three really, b

[Capistrano] Re: changing deploy* behaviour - how should I code this?

2007-01-23 Thread Jeroen Houben
Jamis Buck wrote: > On Jan 23, 2007, at 2:13 AM, jeroen wrote: > > >> Hi Jamis, >> >> It sure is helpful info. However it doesn't completely answer my >> question. My question is more like: how can I can I make sure the >> :repository var *only* changes when I do a deploy or >> deploy_with_migr

[Capistrano] Re: Multiple dirs from one repo?

2007-01-23 Thread topfunky
The cached repository enhancement may also be worth looking at. It does one checkout to the shared dir and rsyncs updates to the current folder. You could modify it to take extra variables corresponding to the parts of the repository that you are deploying. http://pastie.caboo.se/24849 --~--~--

[Capistrano] Re: Cap ShellScriptBuilder

2007-01-23 Thread Jamis Buck
On Jan 22, 2007, at 10:02 PM, Ezra Zygmuntowicz wrote: > So I have worked on this some more to incorporate being abel to set > ENV vars per line if you want. > > sh.RAILS_ENV('production').mkdir_p 'foo/bar' > > #=> RAILS_ENV=production mkdir -p foo/bar Nice! > Jamis asked me to get

[Capistrano] Re: Cap ShellScriptBuilder

2007-01-23 Thread Rob Sanheim
On 1/23/07, NeilW <[EMAIL PROTECTED]> wrote: > > Ezra, > > I appreciate that the method_missing idea has a certain appeal to it, > but does it really save that much time for the aggravation it might > cause? > > I don't see a vast saving between > > sh.rm_rf "fred" > > and > > sh.rm "-rf fred" > >

[Capistrano] Re: Capistrano Hangs on OSX

2007-01-23 Thread Jamis Buck
It sounds like maybe the command you are invoking is not terminating. What commands result in this hanging? The trace you've provided indicates that the connection is alive, and that Capistrano is simply waiting for something on the server-side to finish. - Jamis On Jan 23, 2007, at 12:58

[Capistrano] Re: changing deploy* behaviour - how should I code this?

2007-01-23 Thread Jamis Buck
On Jan 23, 2007, at 2:13 AM, jeroen wrote: > Hi Jamis, > > It sure is helpful info. However it doesn't completely answer my > question. My question is more like: how can I can I make sure the > :repository var *only* changes when I do a deploy or > deploy_with_migrations? What about update_code?

[Capistrano] Re: Multiple dirs from one repo?

2007-01-23 Thread Randall Potter
rylin wrote: > > > Given the example-tree: > A > -1 > --I > -2 > B > -3 > > I might only need to deploy "I" and "3" (e.g., I don't need the > contents of the entire tree, just the contents of I and 3). > > I'm guessing I'll have to start hacking a new update_code task, but > I've no real idea on

[Capistrano] Re: Cap ShellScriptBuilder

2007-01-23 Thread NeilW
Ezra, I appreciate that the method_missing idea has a certain appeal to it, but does it really save that much time for the aggravation it might cause? I don't see a vast saving between sh.rm_rf "fred" and sh.rm "-rf fred" Particularly when you have long strings of options, some of which have

[Capistrano] Re: changing deploy* behaviour - how should I code this?

2007-01-23 Thread jeroen
Hi Jamis, It sure is helpful info. However it doesn't completely answer my question. My question is more like: how can I can I make sure the :repository var *only* changes when I do a deploy or deploy_with_migrations? Just out of interest, I noticed that capistrano has a lot in common with rake,