I don't see how it's misused; ssh is ssh whether your doing it to localhost or otherwise it requires no particular support from capistrano. In both cases you only need to ensure that your ssh client and server are properly configured.
That's the beauty of capistrano being built in ruby; you are free to make the necessary changes to support your core concept. If that isn't what I want out of capistrano I'm free to monkey patch it. As much as I'm a proponent for bending cap where it makes sense; I'm also your biggest supporter of making capistrano narrowly focused on delivering a reliable deployment system. The inspired architecture and openness to be extended will continue to allow me to use it for provisioning. You shouldn't be shackled by anything outside your core concept, I say change what you must and be brutal about adhering to your core concept. On Jun 7, 2012, at 12:48 AM, Lee Hambley <[email protected]> wrote: > > I have a much more liberal view I guess of what capistrano can be leveraged > > for. If you know you have to build a deployment tool to reach remote > > servers; and deploying to localhost allows you to test that pattern before > > you pay for that server then by all means do it with cap. > > I'd say misused, additional use cases outside of the intended make it > increasingly difficult for me to change anything, because I am then breaking > mis-features, and mis-uses of the library; but in open source that's not > something one can ever prevent. > > > However I agree many maintenance tasks are written directly in cap when > > they should be written in rake. > > I'm seriously considering adding a `rake()` command, that's effectively > `run("#{rake} #{task}")` - to encourage this technique, and make it seem more > like someone actually thought about it. > > - Lee > > On 7 June 2012 03:34, Donovan Bray <[email protected]> wrote: > I have a much more liberal view I guess of what capistrano can be leveraged > for. If you know you have to build a deployment tool to reach remote servers; > and deploying to localhost allows you to test that pattern before you pay for > that server then by all means do it with cap. > > However I agree many maintenance tasks are written directly in cap when they > should be written in rake. I create a rake cmd wrapper that I use in those > situations so I can easily call the rake task from cap just as easily as I > could run rake directly on the server via the console. If you ONLY have > those tasks in cap then that is a deployment smell. > > Always leave yourself options. > > > On Jun 6, 2012, at 8:40 AM, Lee Hambley <[email protected]> wrote: > >> Donovan, >> >> Kudos for giving a longer answer, but when you are "deploying" to a local >> server, what you are really doing is building the app, deploying, sort of by >> definition is getting something from somewhere, and putting it somewhere >> else… >> >> I'd argue rake is the correct tool for a *lot* of what people misuse >> capistrano for; and particularly in this case, Rake fits the bill perfectly >> for building/releasing when everything is in one place. >> >> - Lee >> On Wednesday, June 6, 2012 at 5:38 PM, Donovan Bray wrote: >> >>> Possibly if you override the sudo, run, and make them call run_locally >>> >>> That being said I've deployed to localhost by setting up a specific key for >>> the deploy user, and it worked fine and preserved the ability to deploy to >>> stages that weren't localhost. >>> >>> What's so bad about ssh'ing to itself? >>> >>> Other ideas can be found here >>> >>> http://stackoverflow.com/questions/8692664/how-do-i-execute-a-capistrano-task-locally >>> >>> On Jun 6, 2012, at 7:48 AM, jdgriffith <[email protected]> >>> wrote: >>> >>>> I am curious about using capistrano to deploy to the selfsame server on >>>> which the recipe lives on without doing an ssh connection since it is not >>>> needed. Is this something capistrano can do easily or is it mostly used >>>> for remote deployments? >>>> >>>> Regards, >>>> Jdgriffith >>>> -- >>>> * You received this message because you are subscribed to the Google >>>> Groups "Capistrano" group. >>>> * To post to this group, send email to [email protected] >>>> * To unsubscribe from this group, send email to >>>> [email protected] For more options, visit this group >>>> at http://groups.google.com/group/capistrano?hl=en >>> -- >>> * You received this message because you are subscribed to the Google Groups >>> "Capistrano" group. >>> * To post to this group, send email to [email protected] >>> * To unsubscribe from this group, send email to >>> [email protected] For more options, visit this group >>> at http://groups.google.com/group/capistrano?hl=en >> >> -- >> * You received this message because you are subscribed to the Google Groups >> "Capistrano" group. >> * To post to this group, send email to [email protected] >> * To unsubscribe from this group, send email to >> [email protected] For more options, visit this group >> at http://groups.google.com/group/capistrano?hl=en > > -- > * You received this message because you are subscribed to the Google Groups > "Capistrano" group. > * To post to this group, send email to [email protected] > * To unsubscribe from this group, send email to > [email protected] For more options, visit this group at > http://groups.google.com/group/capistrano?hl=en > > -- > * You received this message because you are subscribed to the Google Groups > "Capistrano" group. > * To post to this group, send email to [email protected] > * To unsubscribe from this group, send email to > [email protected] For more options, visit this group at > http://groups.google.com/group/capistrano?hl=en -- * You received this message because you are subscribed to the Google Groups "Capistrano" group. * To post to this group, send email to [email protected] * To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/capistrano?hl=en
