Are you seeing this error when your rails app is running in
development mode, or production mode? If dev mode, I suspect it's
rails' autoload magic that is causing problems. I just threw together
a simple little test script to try and duplicate the problem, and it
works just fine:
~ $ cat y.rb
require 'capistrano/cli'
Capistrano::CLI.parse(%w(-f capfile.test symlink)).execute!
Capistrano::CLI.parse(%w(-f capfile.test symlink)).execute!
No warnings printed or errors raised.
- Jamis
On Jul 2, 2008, at 7:57 PM, ben.koski wrote:
>
> Got the Capistrano::CLI.parse().execute! command working in a process
> forked from the rails app--which I needed to do anyway--but it's still
> strange that it blows up when invoked twice from the same process.
> The capfiles are reasonable staightforward--though I am using the
> ec2onrails gem.
>
> If anyone sees something obvious, let me know!
>
> Here's the code to invoke the cap:
> ----------------
> require 'capistrano/cli'
>
> class DeployManager
> def self.deploy_data
> Capistrano::CLI.parse(['staging',
> 'deploy:db:update']).execute!
> end
> end
> ------------------
>
>
> Capfile:
> ----------------
> load 'deploy' if respond_to?(:namespace) # cap2 differentiator
>
> set :stages, %w(staging production)
> require 'capistrano/ext/multistage'
> ---------------
>
> config/deploy/staging.rb:
> ---------------
> set :application, "myapp"
>
> set :repository, "svn://myrepo/#{application}/trunk"
> set :deploy_via, :copy
> set :copy_stategy, :export
>
> # NOTE: for some reason Capistrano requires you to have both the
> public and
> # the private key in the same folder, the public key should have the
> # extension ".pub".
> ssh_options[:keys] = ["#{ENV['HOME']}/.ssh/mykey.pem"]
>
> role :web, "myserver"
> role :app, "myserver"
> role :db, "myserver", :primary => true
>
> set :rails_env, "staging"
>
> # EC2 on Rails config. Many of these can be omitted if not needed,
> check
> # the documentation.
> set :ec2onrails_config, {
> # S3 bucket and "subdir" used by the ec2onrails:db:restore task
> :restore_from_bucket => "foo",
> :restore_from_bucket_subdir => "bar",
>
> # Set a root password for MySQL. Run "cap
> ec2onrails:db:set_root_password"
> # to enable this. This is optional, and after doing this the
> # ec2onrails:db:drop task won't work, but be aware that MySQL
> accepts
> # connections on the public network interface (you should block the
> MySQL
> # port with the firewall anyway).
> :mysql_root_password => "foobar",
>
> # Any extra Ubuntu packages to install if desired
> # :packages => ["logwatch", "imagemagick"],
>
> # Any extra RubyGems to install if desired: can be "gemname" or if
> a
> # particular version is desired "gemname -v 1.0.1"
> # :rubygems => ["rmagick", "rfacebook -v 0.9.7"],
>
> # Set the server timezone. run "cap -e
> ec2onrails:server:set_timezone" for
> # details
> :timezone => "US/Eastern",
>
> # Files to deploy to the server (they'll be owned by root). It's
> intended
> # mainly for customized config files for new packages installed via
> the
> # ec2onrails:server:install_packages task. Subdirectories and files
> inside
> # here will be placed in the same structure relative to the root of
> the
> # server's filesystem.
> #:server_config_files_root => "../server_config",
>
> # If config files are deployed, some services might need to be
> restarted
> :services_to_restart => %w(apache2 postfix sysklogd),
>
> # Set an email address to forward admin mail messages to
> :admin_mail_forward_address => "[EMAIL PROTECTED]",
> }
>
> require 'ec2onrails/recipes'
>
> namespace :deploy do
> namespace :db do
>
> # main update task -- run this to upload and then swap databases
> task :update, :roles => :db do
> # exec my task
> end
> end
> end
> --------------
>
> On Jul 2, 8:22 pm, Jamis Buck <[EMAIL PROTECTED]> wrote:
>> Could you post your entire script?
>>
>> - Jamis
>>
>> On Jul 2, 2008, at 5:50 PM, ben.koski wrote:
>>
>>
>>
>>> One more headscratcher for tonight:
>>
>>> I'm trying to embed Capistrano into a rails app. I'm using cap 2.4
>>> and capistrano-ext to handle stages. The Capistrano::CLI docs
>>> make it
>>> seem simple enough to call
>>
>>> Capistrano::CLI.parse(['staging', "deploy:db:update"]).execute!
>>
>>> or
>>
>>> config = Capistrano::Configuration.new
>>> config.logger_level = Capistrano::Logger::TRACE
>>> config.load "Capfile"
>>> config.load "config/deploy/staging"
>>> config.set(:stage) {'staging'}
>>> config.deploy.db.update
>>
>>> both of these work _beautifully_ the first time. Problem is, if I
>>> try
>>> to execute this twice it blows up on "ArgumentError: defining a task
>>> named `symlink' would shadow an existing method with that name" in
>>> capistrano/configuration/namespaces.rb.
>>
>>> Makes sense to raise when trying to redefine something, but the
>>> strange thing is that these definitions seem to persist even after
>>> config or event the class making the call to CLI has gone out of
>>> scope--kind of. If I try to run config.deploy.db.update a second
>>> time
>>> without running the config.load, the tasks aren't there.
>>
>>> Any suggestions?
> >
--~--~---------~--~----~------------~-------~--~----~
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/capistrano
-~----------~----~----~----~------~----~------~--~---
