Craig Hockenberry recently emailed me with the solution to a problem
that has bitten several people on this list. The problem is this:
during a deploy, Capistrano would suddenly go off into la-la land and
just hang, and on the server would be a defunct process. An SSH trace
on the client
Just a quick progress report...
I spent the weekend working on the new Capistrano web site. It's not
done yet, so I won't announce anything, but it's coming along and I
hope to have it good enough by tomorrow evening. (*crosses
fingers*) I'm a programmer (and not a designer) for a reason,
Steve,
My apologies, I haven't been ignoring this patch, I promise. I've
just been pushing hard to get cap2 ready to go by railsconf, along
with my (3-hour!) tutorial session, and the rails way presentation
I'm doing with koz.
I'm not 100% sure that I want to put yet another option in the
Hi Dave,
This will actually be one of the supported strategies in the up-
coming Capistrano 2.0. A preview release is coming shortly (e.g., a
few more days).
- Jamis
On Apr 23, 2007, at 3:08 PM, Dave Verwer wrote:
Hi
I recently did some work for a client that had no access to their svn
It is with a great deal of excitement and anticipation that I
announce the first preview release of Capistrano 2.0. This is _not_
an official release, but simply the first of several attempts to get
people using what will eventually be 2.0, so that we can iron out all
the wrinkles. Thus,
, Jamis Buck wrote:
It is with a great deal of excitement and anticipation that I
announce the first preview release of Capistrano 2.0. This is _not_
an official release, but simply the first of several attempts to get
people using what will eventually be 2.0, so that we can iron out all
On Apr 25, 2007, at 6:57 AM, jesse newland wrote:
Thanks Jamis! I've updated most of my recipes, and they're working
great. Now, onto the extensions..
Is there an example anywhere of how extensions should be structured
for 2.0?
Alas, nothing yet. I hope to rectify that today or tomorrow.
Mark,
Because capistrano assumes everything under the project directory is
deployable, the easiest fix might be to rearrange your directory
tree so that the doc directory is elsewhere, e.g.:
* source
- doc
- trunk
And then you deploy source/trunk.
- Jamis
On Apr 25, 2007, at
,
for Capistrano.
- Jamis
On Apr 25, 2007, at 9:57 AM, Carl Lerche wrote:
Just a quick suggestion for the site. I always thought it would be
cool to have a wiki or some place where we all could post and share
our recipes, extensions, cool tricks, etc... in one place.
-carl
On 4/24/07, Jamis Buck
On Apr 25, 2007, at 6:11 AM, Chris McGrath wrote:
We have something hacked up to do something similar to deploy_via,
except we use rsync rather than a straight cp. Would you take a patch
that allowed for a remote_cache_copy_command or something like that?
I'd be willing to consider any new
, Mike Bailey wrote:
I've just read the capify site from start to finish. Great
documentation!
- Mike
On 4/25/07, Jamis Buck [EMAIL PROTECTED] wrote:
It is with a great deal of excitement and anticipation that I
announce the first preview release of Capistrano 2.0. This is _not_
Doug,
Cap should probably be using Dir.tmpdir instead of the current
working directory. I'll make that happen.
- Jamis
On Apr 26, 2007, at 9:36 AM, Doug Barth wrote:
I'm playing around with Capistrano 2.0. The first order of business
for me (after upgrading my recipe of course) is to
Alright, I finished a first pass at a Getting Started guide for
Capistrano (2.0) and Rails (since that will be, for most comers, the
most common use-case initially).
http://www.capify.org/getting-started
http://www.capify.org/getting-started/rails
I'll be adding non-Rails-related
Which deployment strategy are you using? And does the svn executable
exist at /home/x/bin/svn on the machine that is doing the info query?
- Jamis
On Apr 27, 2007, at 2:27 PM, merg wrote:
When doing a cap deploy the cap the
* executing `deploy:update_code'
fails.
I tried the svn info
On Apr 27, 2007, at 3:35 PM, merg wrote:
And does the svn executable
exist at /home/x/bin/svn on the machine that is doing the info query?
svn is on a different location on my local machine, and this is where
it now goes wrong when specifying scm_command.
Gah, you're right, that would be
guh, yeah, that's what I get for not having unit tests for the
deployment code yet. :( The check method for remote deployments
(e.g., checkout based) is broken.
If you open capistrano/recipes/deploy/strategy/remote.rb and find the
def check! method, you can replace it with the following:
Steve,
Ah, yeah, that's confusing. Here's what will work:
deploy.app.desc Start mongrel cluster
deploy.app.task ...
Or
deploy.namespace :app do
desc Start mongrel cluster
task :start ...
end
I'll rethink the decision to put desc as a method of the namespace.
- Jamis
Grrr.
I hate Windows.
Can someone with Windows networking chops take a look at that and see
if they can figure out why Net::SSH is choking? Otherwise, I'm just
going to add a caveat saying Windows users are out of luck and should
not upgrade.
- Jamis
On May 1, 2007, at 2:55 PM, LarryK
Daniel,
Yes, Capistrano was designed with just this setup in mind. You
basically just tell Capistrano that your web server is a gateway
into your other servers:
set :gateway, web.server
role :web, web.server
role :app, app.server
All connections to the servers specified in the
Ah, good catch, Ned. That's bitten others, too; I'd definitely accept
patches to make the subversion module understand non-english locales.
- Jamis
On May 2, 2007, at 4:36 AM, Ned Baldessin wrote:
Issue solved : I was using a french locale, not en_US.UTF-8, so svn
info gave me :
Chemin
On 5/2/07, Jamis Buck [EMAIL PROTECTED] wrote:
On May 2, 2007, at 6:32 AM, [EMAIL PROTECTED] wrote:
I know Jamis is probably working on the tutorial for 2.0.
Can anyone please give share a quick tutorial on the tarball method
for deploying?
First, set the :deploy_via variable
Thanks for raising this, Mike. I've been waiting (since before 1.0)
for this to become an issue, and it looks like the time has come.
Here's what I'm thinking of hacking into cap2:
before :update = :custom_task
after :deploy = :another_task
Also
before :update do
# ...
end
Sounds like this is leaning more towards a kind of tracing/callback
functionality:
on :task_enter = :some_task
on :task_exit = :another_task
That also lends itself to other kinds of hooks, and provides a
supporting infrastructure for the before/after hooks I posted in an
earlier
Yeah, it's a known bug in 1.99.0. A fix was posted here:
http://groups.google.com/group/capistrano/browse_thread/thread/
3b987a204db59842/385fcc82741dfd09#385fcc82741dfd09
(I'm sure that'll wrap, but you can google the capistrano list for
deploy:check and find it if you need to.)
The
Jeff,
The spawner/reaper dance is not specific to fcgi--it's also for
mongrel. That said, if you are using a cluster of mongrel instances,
many people are prefering the mongrel_cluster utility to the rails
spawner. However, one way or another, you're still going to need to
spin up your
That is, as you said, Capistrano being opinionated. cap -T will
only show tasks with descriptions. If you want to show all tasks,
regardless of whether they have a description or not, add a -v:
cap -Tv
That'll give you the full list. Note that if you only do -T, and
there are tasks
to have PR2 ready to announce by the end of this week.
- Jamis
- Mike
On 5/5/07, Jamis Buck [EMAIL PROTECTED] wrote:
Thanks for raising this, Mike. I've been waiting (since before 1.0)
for this to become an issue, and it looks like the time has come.
Here's what I'm thinking of hacking
Very nice! Thanks for sharing this.
- Jamis
On May 3, 2007, at 6:00 PM, [EMAIL PROTECTED] wrote:
In my networks, I need to login to a gateway server through two other
servers.
[my pc] -- [hostA] -- [hostB] -- [gateway] -- [target servers]
so, I extend gateway.rb and make gateways.rb
I'm not sure I understand what you mean by reverse tunnel.
Is the problem that your production environment cannot access your
subversion repository? If so, then the solution is in Capistrano 2.0,
where you can say:
set :deploy_via, :copy
And deployments will then do a local checkout,
This has been fixed in http://dev.rubyonrails.org/changeset/6702. It
will be part of Preview Release 2, later this week.
The above change implements the following:
1. If you set neither :scm_command nor :local_scm_command, the
default will be used for both local and remote hosts.
2. If you
The problem with that, though, is that the configuration instance
(and therefore the logger) are created _before_ the capfile is
loaded. I could see having a new command-line switch that allowed you
to specify the output of the log, but it's not something you can set
in the capfile,
Good catch, Scott. I'll get that patch applied tonight.
- Jamis
On May 10, 2007, at 3:43 PM, Scott Chacon wrote:
In a previous change to copy.rb (6589), the tarball was moved from
being created in the working directory to being created in /tmp.
Doing that made the tar command include the
That's...not recommended. Rake syntax and cap syntax are (perhaps
unfortunately) very similar, but they are not identical. Also,
semantically, Rake tasks and cap tasks are very different. Rake works
by building a dependency graph and executing tasks in the order that
satisfies the
The upcoming Capistrano 2.0 release continues to evolve! Remote
administration of single servers and server clusters has never been
easier. With Capistrano, you can:
* Deploy web applications with a single command
* Keep software in sync across multiple machines
* Install entire servers with
Lee,
Currently, there's not really a way to do it. The Capistrano::Logger
class itself supports an :output option, which can specify either an
IO object or a filename, but the primary logger instance is created
in Capistrano::Configuration#initialize, and there is not any way to
pass
On May 11, 2007, at 1:47 AM, Tim Lucas wrote:
Fantastic work, especially when you're so busy. A quick q:
Thanks!
Why a migrate rather than a db:schema:load for setting up the DB?
Mostly because I don't think it matters 99.9% time on a first deploy,
but also because deploy:migrate already
Actually, the old version of that recipe would work fine in Cap2,
you'd just get a deprecation warning for the
Capistrano.configuration call. There's no need to switch to the new
after() keyword, since after_update_code will continue to work as
before.
If you just want to get rid of the
The core command must be the same on all hosts for cap to run it in
parallel, but cap2 provides a way to substitute the hostname into the
command. Thus, if you have a script for each host, which contains the
commands you want executed on that host, you could then just invoke
the script
On May 18, 2007, at 6:17 AM, Chris Berry wrote:
I have upgraded to Cap2, and what I mention below
run echo \port = #{host_to_port_map[$CAPISTRANO:HOST$]}\
is *not* possible. $CAPISTRANO:HOST$ is treated simply as a
placeholder. It is not evaluated (it is simply substituted), so it
You'll also need to set the :runner variable, which specifies who
sudo will try to run the command as. If, on the other hand, you don't
want that command to use sudo, you'll need to set :use_sudo to false.
set :runner, root # sudo to root
or
set :use_sudo, false # disable sudo
-
Moses,
I really feel that 1.99.1 is pretty close to what 2.0 needs to be.
The big things lacking before I feel confident putting the 2.0
final stamp on it are primarily documentation-oriented. Once I'm
back from vacation (next week), I'll consult with Ezra and Mike and
we'll see where we
As I understand it, the caching stuff simply looks for all files in
(e.g.) public/stylesheets and concatenates them into a single file,
called all.css (or all.js, for the javascript files). Thus, if you
were to create a task that did a cat *.css all.css and then
copied that to your asset
Dan,
Make sure the spin script has the executable bit set, and that the
shebang line (if it exists) points at the correct location for the
shell on the remote host.
- Jamis
On May 21, 2007, at 8:28 AM, DA Hancu wrote:
I am trying to get rails to deploy to OS X server running apache and
Sounds like your :repository variable is set to something invalid, or
unreachable by the remote host. In cap 1.x, both the local host and
the remote host must be able to access the repository as defined in
the :repository variable.
- Jamis
On May 22, 2007, at 8:41 PM, [EMAIL PROTECTED]
Peter,
Do you have a 'zip' command-line utility installed, and is it in the
path?
- Jamis
On May 29, 2007, at 9:50 AM, peterB wrote:
Hi, I got this error when I want to use cap deploy:cold
My computer is on windows and it looks like capistrano cannot make
the .zip, tar .. file and then
As far as I know, Winzip doesn't have a command-line component. If
you open a DOS console and type zip, does anything happen? If not,
you might need to go looking for one... not being a windows user
myself, I can't really help you out there. Perhaps someone else on
the list can offer some
Scott,
What version of capistrano are you using? What does your deploy.rb
look like? Are you using any third-party capistrano extensions?
- Jamis
On May 31, 2007, at 10:45 AM, Scott wrote:
Hi,
I have backgroundrb installed via a svn external in my local env. Now
all of a sudden when I
Do you have the Net::SFTP gem installed?
- Jamis
On May 31, 2007, at 12:17 PM, peterB wrote:
OK, I already found out how to add and compress files with zip utility
but found another bug. The uploaded file is smaller and damaged, so it
can't be uncompressed.
The problem is in copy.rb file
Ah, good catch, Sean. That's exactly it. You can't do File.read
(foo) in Win32, because that opens in text mode. You need to do it
longhand:
contents = File.open(foo, rb) { |f| f.read }
put contents, /path/on/remote/server
- Jamis
On May 31, 2007, at 1:20 PM, Sean Cribbs wrote:
It
demonstrating the use of transactions.
task :long_deploy do
transaction do
update_code
disable_web
symlink
migrate
end
restart
enable_web
end
On 31 May, 10:19, Jamis Buck [EMAIL PROTECTED] wrote:
Scott,
What version of capistrano are you using? What does your
Done! Thanks for the patch, Matt.
- Jamis
On May 31, 2007, at 2:23 PM, Matthew Elder wrote:
Hi guys, this causes deploy to not make assumptions about folders
existing and makes it less brittle on some scms (including mercurial).
Please put it into trunk :)
--Matt
--
Matthew Elder
Alright, I just committed a change to Capistrano that makes it so you
can do:
default_environment[PATH] = /foo:/bar:/baz
All environment keys that you put in the default_environment hash
will be applied to every run() and sudo() call. If you specify
the :env key to run() or sudo(), it
You might need to use nohup. If you go to the google groups page for
the list, you can search for nohup to get a few messages that have
been posted about that strategy:
http://groups.google.com/group/capistrano/search?
group=capistranoq=nohup
- Jamis
On Jun 3, 2007, at 1:55 AM, eden li
You'll need to override (redefine) the task in question, and use
sudo instead of run.
- Jamis
On Jun 3, 2007, at 7:41 AM, doron wrote:
i want a built in task like setup, update_code or symlink to run with
sudo.
how do i do it?
--~--~-~--~~~---~--~~
Does ruby -v do anything? (e.g., is ruby in your path?) How about
gem -v? Is there a 'cap' script in the same directory as your 'gem'
command?
If all else fails, you might just try reinstalling the capistrano gem.
- Jamis
On Jun 4, 2007, at 7:12 AM, Udi Oron wrote:
Hi!
capistrano
on Windows does not run at
all (Rails won't even load) on the Linux server I am using for
deployment.
How do people go about deploying in situations like this?
Is it not possible to deploy an app this way?
On Jun 3, 5:56 pm, Jamis Buck [EMAIL PROTECTED] wrote:
Looks like you need to install
hooks. and also putting my user in a certain group
that has more permissions.
Sounds good!
- Jamis
On Jun 4, 2:01 am, Jamis Buck [EMAIL PROTECTED] wrote:
You'll need to override (redefine) the task in question, and use
sudo instead of run.
- Jamis
On Jun 3, 2007, at 7:41 AM, doron wrote
For a non-rails project, be sure to override the
deploy:finalize_update task, so that it doesn't do anything:
deploy.task :finalize_update do
end
That task contains most of the rails-specific deployment behavior.
- Jamis
On Jun 5, 2007, at 6:18 AM, Valentino Volonghi wrote:
Hi all,
:sequential = true would be a nice option, and I'd certainly
consider a patch for that. In the meantime, it would require some bit
of hackery to make it happen. Essentially, capistrano executes each
command on all matching servers in parallel. To do it in sequence,
you would need to
)
That will give you an array of Capistrano::ServerDefinition objects,
each of which can be queried for the host attribute:
hosts = servers.map { |s| s.host }
Hope that helps,
Jamis
On Jun 5, 2007, at 1:35 PM, Mat Schaffer wrote:
On Jun 5, 2007, at 3:28 PM, Jamis Buck wrote:
:sequential = true
Just to clarify: it _is_ legal to _declare_ a task for a non-existant
or empty role. It just currently raises an exception when you try to
execute that task, if no servers exist in that role at the time.
As for why that is the case, I suppose it's because I couldn't
envision a use case for
Hmmm.
The svn repository you tested on the command-line is not the same one
you have in your deploy.rb (different IP addresses, different
repository path, different user name).
Also, note that the recommended way to set the user name is (in cap2)
with the :scm_username variable:
set
I'm not sure I follow. Both a failed connection and a failed command
cause Capistrano to abort. How is the final result any different?
Your post didn't give much in the way of a use case--could you
explain a bit more here? I'm curious to know how you're using this.
- Jamis
On Jun 7, 2007,
That would be Net::SFTP's fault, and I'd certainly welcome any
patches that made Net::SFTP more optimal. A word of caution,
though...the Net::SFTP code is...messy. It's pretty hard to follow,
and I say that as the author of the library. I'm pretty embarrassed
by both Net::SSH and
wrote:
On 6/7/07, Jamis Buck [EMAIL PROTECTED] wrote:
I'm not sure I follow. Both a failed connection and a failed command
cause Capistrano to abort. How is the final result any different?
Your post didn't give much in the way of a use case--could you
explain a bit more here? I'm curious to know
, Jamis Buck [EMAIL PROTECTED] wrote:
Ah, yes, that does make more sense. What kind of tasks are you
running, where you want them to continue even if a command fails on
one server? I'm curious what uses people are putting Capistrano to,
besides those that I designed it for.
We're using
Thanks, Rob. I've committed it. It also gave me an opportunity to
simplify the upload tests a little bit, since they were failing after
this patch (but only because they were pretty fragile). They're a bit
more robust now.
- Jamis
On Jun 7, 2007, at 4:52 PM, Rob Holland wrote:
Patch
Sean,
I might entertain a patch for that syntax. Could you give a real
example for where it is useful, though? The contrived example makes
it hard to see where the value actually lies.
- Jamis
On Jun 11, 2007, at 7:53 PM, Sean wrote:
Hi all,
I'd like to define a task like the one
Rob,
Could you send a single patch with all of the changes aggregated? I'm
a little confused as to whether this patch replaces all previous
ones, or just augments them.
Also, I'm thinking that instead of :best_efforts = true, it might be
cleaner to say :on_error = :continue, with the
Perhaps this only tickles me because I'm the author of the software,
but apparently the next version of Mac OS X will ship with
Capistrano, bundled. (see http://www.apple.com/macosx/leopard/
technology/unix.html) No doubt it will ship with 1.4.1, but this is
getting me motivated again on
What OS are you deploying to?
- Jamis
On Jun 10, 2007, at 12:22 PM, gcnovus wrote:
FWIW, doing the process manually:
svn export http://repository 20070610183345
tar -czvf 20070610183345.tar.gz 20070610183345/
scp 20070610183345.tar.gz [EMAIL PROTECTED]:/tmp/
works fine, but it does
It just means you can use any valid svn repository URL (although, as
noted, cap1 doesn't work with file: URL's out of the box. cap2 does.)
Thus, you can use http if your setup supports it, or you can use svn
+ssh (or anything else might have configured).
- Jamis
On Jun 13, 2007, at 1:25 AM,
Where is deploy.rb located? What directory are you in when you run
cap setup?
- Jamis
On Jun 13, 2007, at 12:07 PM, charlie caroff wrote:
Hi,
I am struggling with understanding how deploy.rb works. I'm using svn
+ssh. I'm running capistrano 1.4.1 for FreeBSD ports. I'm not using
a
Looks like the problem is this:
ssh: connect to host 192.168.1.151 port 22: Operation timed out
Also, note that rake integration is deprecated, and is entirely gone
in cap2. You should be using 'cap' directly, rather than via rake.
- Jamis
On Jun 13, 2007, at 2:21 PM, charlie caroff
, cap) is going to be shipped in good
working order? I remember some issues with how the ruby that shipped
with 10.4 was a little wonky if I'm not mistaken.
DHH has contacts there, and has been in touch.
- Jamis
Thanks and congrats!
Glenn
On 12 Jun, 08:23, Jamis Buck [EMAIL PROTECTED] wrote
On Jun 13, 2007, at 5:05 PM, charlie caroff wrote:
Also, note that rake integration is deprecated, and is entirely gone
in cap2. You should be using 'cap' directly, rather than via rake.
Thanks. I seem to get better error messages, though, when I use rake
deploy. Is there way to run cap
On Jun 13, 2007, at 6:06 PM, charlie caroff wrote:
Also, note that rake integration is deprecated, and is entirely
gone
in cap2. You should be using 'cap' directly, rather than via rake.
When you say cap2, do you mean that capistrano has a version 2? The
latest version I see is 1.99.
DESC
run mongrel_command do |channel,stream,data|
channel.send_data(password\n)
end
end
On 6/14/07, Jamis Buck [EMAIL PROTECTED] wrote:
There's not really a special syntax for delayed evaluation of roles,
but you can programmatically set roles in tasks:
task :set_roles do
If all else fails, the best way to troubleshoot these things is to
take the commands that cap is trying to execute, and run them
yourself. Just log into your server, and copy and paste the commands
in, one at a time.
It really looks like the problem is with your public/ or /u/apps/
Another option, if it is just a single file; you can declare declare
the server in question to be :no_release = true, and then just use
put to upload the file to wherever you need it:
# :no_release = true prevents the app from being deployed to this
server
role :other,
in '/u/apps/
project/current/tmp/pids' matching 'dispatch.[0-9]*.pid'
** [out :: www.project.com]
** [out :: www.project.com] (also looked for processes matching /u/
apps/project/current/public/dispatch.fcgi)
** [out :: www.project.com]
command finished
On Jun 14, 6:54 am, Jamis Buck
Thanks, Chris. I've made that correction.
Capistrano shares the same svn repository and Trac instance as Rails,
so you can post bug reports and patches there:
http://dev.rubyonrails.org
Thanks!
- Jamis
On Jun 15, 2007, at 3:03 PM, Chris Bailey wrote:
In the Capistrano 1.99.1 code, and
?
1.99.2 will be out tonight or tomorrow. And the good news is that the
prospects are bright for Mac OSX Leopard bundling cap2. :)
- Jamis
On 6/15/07, Jamis Buck [EMAIL PROTECTED] wrote:
Thanks, Chris. I've made that correction.
Capistrano shares the same svn repository and Trac instance
Yes, 1.99.2 will include the Perforce typo correction.
- Jamis
On Jun 15, 2007, at 3:54 PM, Chris Bailey wrote:
Cool (on all accounts!). Will this change be in it?
On 6/15/07, Jamis Buck [EMAIL PROTECTED] wrote:
On Jun 15, 2007, at 3:25 PM, Chris Bailey wrote:
Thanks Jamis! Good
Alright, we're nearing the finish line! Capistrano 2.0 Preview
Release #3 is now available.
To install Preview #3, you'll need to grab it from the Rails beta gem
server:
gem install -s http://gems.rubyonrails.org capistrano
Accompanying PR3 is a new page of documentation on the
On Jun 16, 2007, at 6:17 AM, Valery wrote:
to my understanding Cap2 PR3 have (at least) two following issues.
1. PR3 contains many entries with hardcoded user app.
maybe it is a good idea to get rid of this 37sig backtrace
before Cap2 is out. Things like
cap deploy:start
cap
Cap 1.99.2
On Jun 16, 11:56 am, Jamis Buck [EMAIL PROTECTED] wrote:
That's...odd. If you fire up irb, and type:
gem capistrano
require 'capistrano/ssh'
p Capistrano::SSH
What happens? What version of Ruby are you using? What version of
Capistrano did you have installed
In cap2, it's the :runner variable. Make sure you set that to the
user you want to run your processes as.
- Jamis
On Jun 17, 2007, at 12:33 AM, [EMAIL PROTECTED] wrote:
When I do a cap deploy:cold everything works successfully until I get
to here...
* executing `deploy:start'
*
This is very likely due to a bug that I just fixed; type -p is not
available on the vanilla POSIX shell, but is what cap 1.99.2 uses to
determine whether a command exists in the path. I committed a change
that uses which instead, which should be more portable. If you open
Dmitry,
Can you tell me what OS you are running locally? Also, what Ruby
version do you have installed locally? What versions of Net::SSH and
Net::SFTP do you have installed? And how large is mapscript.so?
- Jamis
On Jun 18, 2007, at 12:46 AM, Dmitry Kurochkin wrote:
Hi Capistrano devs.
Try this:
set :deploy_via, :export
- Jamis
On Jun 18, 2007, at 12:14 PM, [EMAIL PROTECTED] wrote:
What is the command to force an svn export, vs a checkout in
capistrano 2?
In prior versions, (set :checkout, export) did the trick, but cap 2
doesn't want to play nice with the same
Declaring two tasks in the same namespace with the same name will
cause the second definition to overwrite the first. What you want is
to chain behavior onto some base implementation. Assuming
mongrel_cluster provides some implementation for deploy:start, all
you have to do, then, is
(Pardon the slightly off-topic post, but since Capistrano builds on
top of Net::SSH, I figured a release-announcement here would be
useful to most of you.)
Net::SSH 1.1.2 is now available! You can install it via RubyGems:
gem install net-ssh
Or download the source package of your choice
Sorry, I missed your other two questions. :) Oops:
On Jun 18, 2007, at 11:05 AM, Claudio Poli wrote:
Also, I was having some trouble when writing files.
mongrel_cluster has a system command to spit out a config file, based
on parameters, backgroundrb don't (although it has the -l switch).
. Make sure you can issue the
sftp call from the command line...
On 18 Jun, 06:59, Jamis Buck [EMAIL PROTECTED] wrote:
Dmitry,
Can you tell me what OS you are running locally? Also, what Ruby
version do you have installed locally? What versions of Net::SSH and
Net::SFTP do you have installed
, 2007, at 3:42 PM, Dmitry Kurochkin wrote:
Hi Jamis,
I'm running Debian unstable,
ruby 1.8.6 (2007-03-13 patchlevel 0) [i486-linux],
net-sftp (1.1.0),
net-ssh (1.1.1).
mapscript.so is 1.4 MB.
Regards,
Dmitry
On 18 июн, 16:59, Jamis Buck [EMAIL PROTECTED] wrote:
Dmitry,
Can you tell
Yeah, you can't really use csh or tcsh with cap, because it assumes
that the following is valid:
NAME=VALUE NAME=VALUE command arguments
In other words, it assumes you can add to the command environment by
prefixing the command with name=value pairs.
I do know what the problem here is,
It looks like Capistrano needs to execute the commands like this:
A=B X=Y sh -c command command command
That, or:
export A=B X=Y command command command
The latter would probably be less prone to quoting problems. It might
eventually be more easily extended to support non-POSIX
Thanks for the suggestion, Drew. `env' is definitely a better option
there.
- Jamis
On Jun 19, 2007, at 9:51 AM, Drew Raines wrote:
Jamis Buck wrote:
It looks like Capistrano needs to execute the commands like this:
A=B X=Y sh -c command command command
That, or:
export A=B
Amr,
I just tried installing capistrano on WinXP, and got the same error.
I'm afraid I have no suggestions at this point, aside from the
(certainly unhelpful) observation that it works fine on Mac OSX. :/
- Jamis
On Jun 19, 2007, at 11:18 AM, Amr Malik wrote:
I have upgraded my gem
101 - 200 of 1085 matches
Mail list logo
