This one concerns using capistrano for Rails deployment, and git for version control. I got stuck for quite some time on this.

PROBLEM: I could ssh into my target prod server, and from there ssh into my repo server (for git) fine. When I run “cap deploy:update” it seems when the capistrano scripts running on my target prod server get a “failed password” when trying to access the repo server.

After some great help from Jamis Buck (developer of capistrano) the problem became clearer.

ANSWER: Set the following variable in the capistrano “./config/deploy.rb” file.

"default_run_options[:pty] = true"

FURTHER INFO (from Jamis)

By default, Capistrano WILL load ~/.bashrc for each command (since
about cap 2.4 or so). However, this default causes problems with
interactive processes, like sudo or svn or other processes that may
want to prompt for input. Thus, it is common for people to tell
Capistrano to request a pty from the server, via
default_run_options[:pty] = true. However, when cap requests a pty,
the shell will not load the user's profile script.

There's no good solution for this, except to NOT rely on your .bashrc
(or similar) script. What kinds of things are you expecting to be set
that way?

You can mimic a pty-less SSH session like this:

 ssh -T host.com "git clone -q /repos/equity/.git /tmp/test"

Likewise, you can mimic SSH session with pty-allocation like this:

 ssh -t host.com "git clone -q /repos/equity/.git /tmp/test"

(pty-allocation is the default for openssh, but the difference there
is that ssh requests an interactive user shell, and capistrano does
not.)

Solution:
rake spec:rcov && open coverage/index.html

undefined method `account_item_id=' for #

When I did the same thing the test spec was doing in the rails console (i.e. ./script/console) things worked fine. Couldn’t work it out.

Solution: You may have guessed it. The tests work on the “test” database, not the “development” database. I needed to run the “rake db:migrate RAILS_ENV=test” to bring my test database schema up to date. Doh!

Solution: Here’s the solution (updated from Paul’s suggestion below):

 “svn add * –force” This will recursively add new files and skip any files that are already in svn.

The original solution I was using was the below:

svn status | grep "^\?" | awk '{print $2}' | xargs svn add

Console Output Highlight the Issue

>> a = Allocation.new
=> #<Allocation id: nil, transaction_id: nil, person_id: nil, recurring_id: nil, amount: nil, amount_percent: nil, created_at: nil, updated_at: nil>
>>
?> a.valid?
=> false
>> a.amount = 1
=> 1
>> a.transaction_id = 1
=> 1
>> a.person_id = 1
=> 1
>>
?> a.valid?
=> true
>>
?>
?> a.save
=> nil
>> a.save!
=> nil

SQL Commands Observed

Transaction Columns (0.003291)   SHOW FIELDS FROM `transactions`
  Transaction Load (0.001494)   SELECT * FROM `transactions` WHERE (`transactions`.`id` = 1) 

Model Code

class Allocation < ActiveRecord::Base
  belongs_to :person
  belongs_to :transaction

  validates_numericality_of :amount, :if => :amount
  validates_numericality_of :amount_percent, :if => :amount_percent

  private

  def validate
    errors.add_to_base('amount and amount_percent can not both be specified') if amount &amp;amp;amp;amp;&amp;amp;amp;amp; amount_percent
    errors.add_to_base('either amount OR amount_percent must be specified') if !amount &amp;amp;amp;amp;&amp;amp;amp;amp; !amount_percent
  end  

end

Can you see the issue? (I couldn’t)

Solution:Transaction is a reserved class in Rails, and it was the name of one of my models, in this case it was one that my “Allocation” model had an association with. The “belongs_to transaction” line was creating a “transaction” method for reading the association. This overwrote an internal method called transaction. The internal method just runs its block inside a database transaction and is used on saves etc… By replacing that with a transaction method that does nothing with the block you completely neutre activerecord.

For a list of Rails reserved words see: http://wiki.rubyonrails.org/rails/pages/ReservedWords

I’ll be starting the renaming of the model “transaction” that I had shortly

Acknowledgements:Ryan Bigg, Frederick Cheung and Chris Bartlett from the Rails mailing list. Thanks guys.

Solution: Run up a server in a separate terminal to view the SQL statements (i.e. ./script/server). They appear here fine.

[root@home current]# rake db:migrate VERSION=production
(in /u/apps/myequity/releases/20081206042650)
rake aborted!
No such file or directory - /tmp/mysql.sock
(See full trace by running task with --trace)

Do you see the problem? What if I show you the db:migrate help…

[root@home current]# rake -D db:migrate
(in /u/apps/myequity/releases/20081206042650)
rake db:migrate
    Migrate the database through scripts in db/migrate. Target specific version with VERSION=x. Turn off output with VERBOSE=false.

So basically I was using VERSION rather than RAILS_ENV (which isn’t mentioned in the description) Things worked fine after issuing the correct line:

[root@home current]# rake db:migrate RAILS_ENV=production
(in /u/apps/myequity/releases/20081206042650)
[root@home current]# 

This blog captures the learnings of a hobbyist Ruby on Rails developer as he stumbles through the word of web development.   Hopefully someone might even learn something…