In this post I’ll explain how to create a node package complete with tests and documentation.

Step 0 - Install the pre-req’s

Note the env stats above. I used Homebrew to install Nodejs v0.4.7 and then followed the manual git clone and ‘sudo make install’ procedure for installing npm. I ran into some permission issues using the one liner on the nmp website. I’m not pro enough to tackle internal node install errors yet. The manual git checkout, sudo make install, worked just fine.

Step 1 - Some background

I suggest you take a look at this: http://howtonode.org/introduction-to-npm This is a good introduction to the node package management system. Pay close attention to the Development section. Note what the author says about creating an node package from the get-go, not as an after thought. I could not agree with this more. Let’s have some fun!

Step 2 - Create your package.json file

It’s a good idea to write most of your Node.js application as a node package. The node package system will help you manage dependencies and other project related tasks for you. You can reuse and share these packages through the npm registry. Also, a package is much easier to test than a full blown application. These points, plus the ease of the ‘npm link’ which links your live development changes into your local node env, gives you no excuse not to go the app-as-a-package route right from the start.

Every package has to have a few things; a name, a version, a description, an author, a repo home, etc… All this info has to be in a special format inside your package.json file. Thankfully there is a simple tool to set this up for you (interactively) called ‘npm init’.

First we create a folder for our project:

mkdir filecore
cd filecore

Then we run the ‘npm init’ command and answer some questions.

npm init

After you finish, it will create the following structure for you. Yours will be different if you answer the questions differently.

{
  "author": "Brian Chamberlain ",
  "name": "filecore",
  "description": "Manages the files and directories of a Naccelle project",
  "version": "0.0.1",
  "repository": {
    "type": "git",
    "url": "git://github.com/breakpointer/filecore.git"
  },
  "main": "filecore.js",
  "engines": {
    "node": "~0.4.7" #<<== NOTE: There is no 'v' in this version number
  },
  "dependencies": {},
  "devDependencies": {}
}

Note: I had to tweak the output of the ‘npm init’ script to remove the letter ‘v’ it was putting in the the “node” attribute. Prior to my edit, the output for that section was “~v0.4.7” which is not correct. “~0.4.7” is the proper format.

This is just a start for this file… there are a number of other options you can configure. See this page for more info: https://github.com/isaacs/npm/blob/master/doc/json.md

Step 3 - Basic package structure

If you note from the package.json file above we’ve stated that our “main” is something called “filecore”. It doesn’t have to match the name of your project but it does have to be where you actually want to mount your app.

You should create a file with the name you specified as your “main”. In my example I’ll create one called ‘filecore.js’. In this file you’ll have to “export” the methods that you want available to the consumers of your package. In other words, when you do something like:

var fc = require('filecore');

The variable ‘fc’ will have the methods attached to it which you export. See the code below.

// Requires go here
// var x = require('x');
// var y = require('y');
// ...etc..

exports.method_a = function(){
 // do stuff here
}

exports.method_b = function(){
  // do stuff here
}

Step 4 - Test driven development

I’m a big fan of test driven development. While I don’t always practice test-first development (because frankly, that kinda takes the fun out of hacking on some new code) but when I have solid idea of what I want a piece of code to do I’ll lay down some tests. A good test base can help propel your development and catch those “I swear I didn’t change anything and now it’s broke!” kinda errors that can pop up from time to time.

I’ve used Jasmine on other JS based projects and found it to have a nice syntax and having built in mocking is nice too. Here’s a link to the project: http://pivotal.github.com/jasmine/

For a Node.js version of Jasmine, see this page: https://github.com/mhevery/jasmine-node. It installs just like any other Node.js package. I installed it globally because I intend to use it on other projects (hence the ‘-g’ option)

npm install jasmine-node -g

In the git repo for the jasmine-node package there are some example spec files to help you get going. Here’s my current project tree:

..README
..package.json
..filecore.js
..spec/filecore_spec.js

And as far as the code is concerned here are the filecore.js and the filecore_spec.js files:

//filecore.js

exports.method_a = function(){
 // do stuff here
 return('a');
}

exports.method_b = function(){
  // do stuff here
  return('b');
}

//filecore_spec.js

var fc = require('../filecore.js');
describe('jasmine-node', function(){

  it('should pass', function(){
    expect(fc.method_a()).toEqual('a');
  });

  it('should pass', function(){
    expect(fc.method_b()).toEqual('b');
  });

});

These tests and code are very trivial but they make sure we’ve setup our Node.js module properly and that our test suite works.

When you run the test suite you should see the following:

brian$ jasmine-node spec
Started
..

Finished in 0.002 seconds
1 test, 2 assertions, 0 failures

* That’s all for this part. In Part 2 I will go through fleshing out the filecore module and how to package and publish your Node.js package.*

In this post I’m going to cover how to make a Rails specific gem using jeweler, how to embed a test rails app in the gem, and how to test your gem code with rspec.

I have a gem that I’ve helped build. It’s called Surveyor. We’ve used it on several of our apps here at NUBIC and it’s been working out pretty well.

I’ve never been happy with our test suite. It’s very temperamental. For the longest time it had to run it inside of an app that had been built just for testing and development purposes which is annoying. Also, it is another barrier to having people in the budding Surveyor user group help out, add features, etc, etc… Not having a proper test suite is somewhat irresponsible, time to correct that problem so development can move forward at full speed.

Surveyor now is working fine as a standalone gem and the specs run inside the gem repo and use the Rails app context.

Step 1 - Jeweler

We started using Jeweler for Surveyor some time ago. It seems to work well. We’re going to use it here.

Get Jeweler from Rubygems. Here’s the github page with instructions on how to install the gem. The version I use in this example is version 1.4.0. Follow the instructions in the Readme on the github page or the downloaded gem. Also remember to run jeweler --help to see all the params you can pass in. The gist of the process is:

jeweler [options] <name_of_gem>

For this example I’ll pretend I’m creating a gem to help us have customized Rails log reporting. I’m going to call my gem ‘bclog’ (bc is for bio-computing, though coincidentally ‘bc’ are also my initials). This gem will be tested with cucumber and rspec so I’ve included those options when running the jeweler command. See below:

brian$ jeweler --rspec --cucumber bclog
create  .gitignore
create  Rakefile
create  LICENSE
create  README.rdoc
create  .document
create  lib
create  lib/bclog.rb
create  spec
create  spec/spec_helper.rb
create  spec/bclog_spec.rb
create  spec/spec.opts
create  features
create  features/bclog.feature
create  features/support
create  features/support/env.rb
create  features/step_definitions
create  features/step_definitions/bclog_steps.rb
Jeweler has prepared your gem in bclog

Great! If you cd into your new gem dir you’ll be able to run $ rake -T and see all the neat things Jeweler can do for you. We won’t be covering any of those tasks here but it’s good to know that Jeweler has a lot of helpful features for your gem development.

Step 2 - Our dev gemset with RVM

Before we get going into modifying our gem we’ll need to set up our development gemset. To do this you’ll need RVM installed. I highly recommend using RVM for development. Even if you don’t have need for multiple ruby versions the ability to easily setup gemsets on a per-directory level is VERY helpful.

I’m assuming you’ve installed RVM, follow these instructions to install RVM if you don’t have it. To create a gemset stand in our new gem directory and run the command below. For more info on RVM Gemsets see this page.

rvm gemset create bclog

We’ll want to have this gemset being used every time we work on this project. Create an .rvmrc file in the project so that everytime you change to this directory the gemset is auto-loaded. One less thing to worry about. Here’s some more information on the RVM site about the workflow.

echo 'rvm_gemset_create_on_use_flag=1; rvm gemset use bclog' > .rvmrc

Now when we cd into the directory we’ll automatically start using this gemset. Give it a try now to make sure it’s working. cd up one dir and back into the project dir. You’ll see a warning message the first time you do this (say ‘yes’ to the message).

Step 3 - Bundler and Gemfile

In the gemset for the gem, install Bundler (1.0.3 as of writing).

Running gem list should show two gems installed; bundler and rake. See below:

brian$ gem list

*** LOCAL GEMS ***

bundler (1.0.3)
rake (0.8.7)

Create a file called Gemfile in your project directory. Load it up with the Gems we need at this point.

source :rubygems

gem 'jeweler'
gem 'rspec', '~> 1.3'
gem 'rspec-rails', '1.3.3'
gem 'cucumber', '~> 0.8.0'
gem 'rails', '2.3.10'

Save this file and then run bundle install

This should install some gems into your local gem bundle.

Step 4 - First gem build and dev setup

Now that your gems are installed (specifically jeweler at this point). Run rake -T to see the Jeweler tasks available to you. What we need to do at this point is setup the gem we’re building so when we include it in our Gemfile as a local, path specific gem, bundler will recognize it as a gem. This means, having a version number and a .gemspec file.

I opened up my Jeweler generated file lib/bclog.rb and added a module definition… it’s for fun at this point. We’ll be adding more to this file later.

module Bclog
# Awesome code goes here...
end

Now run some commands!

brian$ rake version:write
Updated version: 0.0.0

brian$ rake gemspec
Generated: bclog.gemspec
bclog.gemspec is valid.

Pop over to your Gemfile and add the line below. Substituting ‘bclog’ with the name of your gem. This tells bundler to load up the gem your building into the gemset for the project.

plugin_root = File.dirname(__FILE__)
gem 'bclog', :path => plugin_root

Run the install command for bundler

bundle install

Look for your gem in what is printed to the command line. You should see something like this: Using bclog (0.0.0) from source at /Users/brian/bclog

Step 5 - Rake tasks for building test app

Now we are going to create some rake tasks to handle the setting up and tearing down of the test Rails app we’re going to embed in our spec folder. In the Rakefile for this new gem add the following lines from this gist

If you run Rake -T now you should see these new tasks:

rake testbed:build_app               # Install rails base app in spec dir
rake testbed:copy_files              # Copy in setup files to test app
rake testbed:install_surveyor        # Install surveyor in rails base app, runs migrations, preps for testing 
rake testbed:remove_app              # Remove rails base app in spec dir
rake testbed:setup                   # Setup for the test app (create)
rake testbed:teardown                # Teardown for the test app (remove)

There are a few files you’ll need to put in your gems spec directory. These are files that are specific to your development and bundler environment. There is a rake task called testbed:copy_files that will copy the files from the base of the spec folder to where they should belong inside your test rails app. Here are the files as gists: testboot.rb, testpreinitializer.rb, test_Gemfile

After you have created these files in your spec/ folder in the gem you can run the rake testbed:setup task to install the rails app in your spec folder.

Running this task should put a lot of output to the console, it’s running a Rails generator, installing a bundle, copying files, etc… When it’s done you should see a test_app folder in your spec directory.

Step 6 - Start your testing!!

At this point I’ve covered the basics and you should be ready to start writing and running tests on your gem as you would in a Rails app (ie rake spec, rake features).

Note: For a good overview of Rakefiles and their usage see this blog post by Jason Seifer.

I have a gem that I am working on. For development I use bundler and have a hard coded :path to where the gem source code is located. This allows me to develop in the context of a Rails app and have any change I make to the gem immediately available it the app. This works fine except for the generators in the gem.

With a Gemfile like this source :rubygems

gem 'rails', '2.3.10'
gem 'surveyor', :path => '/Users/brian/Rails/surveyor_for_dev'

I get “Couldn’t find ‘surveyor’ generator” when I run bundle exec script/generate surveyor from the cmd line.

If I change that line in the Gemfile and remove everything after the “gem ‘surveyor’” part, bundle install, and run the same command, everything works fine.

What I’ve had to do is use the gem for running the generators, then remove the gem from the system (or gemset) and rebundle. This way I can work on the gem despite the issue bundler is causing.

This problem has something to do with how Rails looks up generators, bundler is not providing the gem generators for local gems to Rails in the proper way.

I don’t have a good solution at this time for the problem. It’s just something to keep in mind when doing Rails gem development using bundler.

Step 1) Make sure you have installed Ruby, Rubygems, Passenger.

Also, make sure you have installed the Passenger apache module. Instructions are on the Phusion webpage. The instructions that are generated in the terminal are not entirely correct with regards to how you should configure Apache for multiple apps. Don’t let this throw you off, do everything else except the Rails app configuration stuff. That part is described below.

NOTE* Before we get to the configuration stuff; just a reminder to create copies of the files before you start editing them. Name them http-conf.old and hosts-old (for example). Just make sure you don’t have the old conf file end in “.conf” Apache will read any .conf file and load it.

Step 2) Configure Apache to handle named hosts and the one, or more apps your going to have it run.

To do this you’ll need to add a few configuration lines to your Apache httpd.conf file. You should find it under /etc/apache2/http.conf I always add the lines to the end of the file so it’s easy to locate. The file is quite long.

#This allows apache to have name based virtual hosts. can listen on the same Ip. by defualt it does not do this 
NameVirtualHost *:80

<VirtualHost *:80>
  ServerName registar.dev
  DocumentRoot "/Users/brian/Rails/registar/public"
  RailsEnv development
  RailsAllowModRewrite off
  <directory "/Users/brian/Rails/registar/public">
    Order allow,deny
    Allow from all
  </directory>
</VirtualHost>

<VirtualHost *:80>
  ServerName enotis.dev
  DocumentRoot "/Users/brian/Rails/enotis/public"
  RailsEnv development
  RailsAllowModRewrite off
  <directory "/Users/brian/Rails/enotis/public">
    Order allow,deny
    Allow from all
  </directory>
</VirtualHost>

The first line tells Apache to accept named based virtual hosts. This will allow your apps to be accessible at http://myapp.dev instead of the usual http://localhost:3000. Much shorter, and more descriptive. You can see from the code above that I’ve got two apps I’m serving from here, one called Registar and the other called eNOTIS. The ServerName in the VirtualHost block configures how I refer to the app in the browser, the DocumentRoot sets where the apps public folder lives on my filesystem, RailsEnv sets the running environment, and I’m not too sure what the other lines do. I will have to do some more research and update the post. I’m guessing it’s got something to do with access permissions and such and where the request can originate from. Here’s the Apache docs on the config settings.

Step 3) Modify your host file

The hosts file is located in /etc/hosts on your OS X file system. This file is what is used by the OS to figure out where to find http://enotis.dev (in my case) on the network. There isn’t a DNS server out there telling the computer to that this is on my computer (nor should there be). The hosts file is a DNS shortcut to resolve the location (i.e. the IP) of named hosts. Here’s what mine looks like after editing it for the two apps I want to run.

##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting.  Do not change this entry.
##
127.0.0.1 localhost enotis.dev registar.dev
255.255.255.255 broadcasthost
::1             localhost 
fe80::1%lo0 localhost

You can keep adding apps to the end of the 127.0.0.1 line, just follow the formatting above. I think the other lines are used by BonJour and such. More can be read about this file on the Apple webpage or by typing ‘man hosts’ in the terminal

Step 4) Restart Apache

We made some pretty big changes so you’ll need to restart Apache before they’ll take effect. To do that from the terminal type

sudo /usr/sbin/apachectl restart

note: see the update below if this causes an error when you run it

Step 5) View your Rails apps

At this point you’ve restarted Apache, and told it where to find your Rails apps. If you go to http://.dev you should see your app. If not, see below.

HELP it doesn’t work!!!!

Well, this does happen from time-to-time. When I was figuring all this stuff out I ran into lots of problems. For a while Apache was serving up one app instead of two, Passenger started crashing, Apache started crashing and failing to restart, etc… etc… Use the logs on the system to help you figure out what is going on. Tail them as you make http requests in the browser to your apps URLs. There are two logs, accesslog and errorlog. Use them well.

tail -n 100 -f /var/log/apache2/error_log

Also take a look at any console message if you’ve hosed your config so bad it’s not doing anything at all. The app is called “Console”, spotlight search for it or look in your Apps/Utilities folder.

home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/activesupport-2.3.9/lib/active_support/dependencies.rb:466:in `load_missing_constant': uninitialized constant Rails::Railtie (NameError)
from /home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/activesupport-2.3.9/lib/active_support/dependencies.rb:106:in `const_missing'
from /home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/rspec-rails-2.0.1/lib/rspec-rails.rb:3
from /home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/bundler-1.0.3/lib/bundler/runtime.rb:64:in `require'
from /home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/bundler-1.0.3/lib/bundler/runtime.rb:64:in `require'
from /home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/bundler-1.0.3/lib/bundler/runtime.rb:62:in `each'
from /home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/bundler-1.0.3/lib/bundler/runtime.rb:62:in `require'
from /home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/bundler-1.0.3/lib/bundler/runtime.rb:51:in `each'
from /home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/bundler-1.0.3/lib/bundler/runtime.rb:51:in `require'
from /home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/bundler-1.0.3/lib/bundler.rb:112:in `require'
from /home/brian/Rails/base_app_for_surveyor239/config/boot.rb:119:in `load_gems'
from /home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/rails-2.3.9/lib/initializer.rb:164:in `process'
from /home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/rails-2.3.9/lib/initializer.rb:113:in `send'
from /home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/rails-2.3.9/lib/initializer.rb:113:in `run'
from /home/brian/Rails/base_app_for_surveyor239/config/environment.rb:9
from /home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/rails-2.3.9/lib/commands/generate.rb:1:in `require'
from /home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/rails-2.3.9/lib/commands/generate.rb:1
from script/generate:3:in `require'
from script/generate:3

Turns out, if you have gems in your Gemfile that are not locked to a know version that works in 2.3.9 you may get this error. It won’t make any sense because the error is inside Bundler and looks like it starts in your config/boot.rb file. Comment out all your gems except Rails and try, one at a time, uncommenting each gem, running bundle install until you find out which gem is causing the problem. It goes to show that you should pay attention to which versions of the gems you have installed and be explicit about them. Even if you are just starting a new app.

Here were the gems I had in my apps Gemfile.

gem "cucumber"
gem "rspec"
gem "rspec-rails"
gem "factory_girl"

Commenting them out stopped the error. Now I have to figure out which versions of these work with Rails 2.3.9 and lock them down to those versions.

Note: I tried rolling back to earlier versions of rails and bundler. It also happens in Bundler 0.9.* and Rails 2.3.5-8

/home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/activesupport-2.3.9/lib/active_support/dependencies.rb:466:in `load_missing_constant': uninitialized constant Rails::Railtie (NameError)
from /home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/activesupport-2.3.9/lib/active_support/dependencies.rb:106:in `const_missing'
from /home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/rspec-rails-2.0.1/lib/rspec-rails.rb:3
from /home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/bundler-0.9.26/lib/bundler/runtime.rb:46:in `require'
from /home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/bundler-0.9.26/lib/bundler/runtime.rb:46:in `require'
from /home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/bundler-0.9.26/lib/bundler/runtime.rb:41:in `each'
from /home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/bundler-0.9.26/lib/bundler/runtime.rb:41:in `require'
from /home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/bundler-0.9.26/lib/bundler/runtime.rb:40:in `each'
from /home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/bundler-0.9.26/lib/bundler/runtime.rb:40:in `require'
from /home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/bundler-0.9.26/lib/bundler.rb:89:in `require'
from /home/brian/Rails/base_app_for_surveyor239/config/boot.rb:119:in `load_gems'
from /home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/rails-2.3.9/lib/initializer.rb:164:in `process'
from /home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/rails-2.3.9/lib/initializer.rb:113:in `send'
from /home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/rails-2.3.9/lib/initializer.rb:113:in `run'
from /home/brian/Rails/base_app_for_surveyor239/config/environment.rb:9
from /home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/rails-2.3.9/lib/commands/generate.rb:1:in `require'
from /home/brian/.rvm/gems/ree-1.8.7-2010.02/gems/rails-2.3.9/lib/commands/generate.rb:1
from script/generate:3:in `require'
from script/generate:3

Ultimately, this data will end up (at least part of it) in a relational DB but setting up the needed tables, columns, etc… require a lot upfront to build out the all that good relational-ness. At this point, it’s pretty exploratory. As I add more webservice calls I’d like to immediately see that data and use it in my app. Not have to write a migration that I may or may not have to roll back if the additional data element is wrong or not needed. I’m trying to keep it agile over here!

So, I have my code query the remote web service and I get back a hash for each object I want to put in my CouchDB database (conveniently I designed this code to turn ugly SOAP mapping objects into plain old arrays of hashes). The initial web service query returned over 12,000 objects so iterating over each one to stuff into the CouchDB seemed silly. Luckily CouchDB can handle bulk document creation (using the CouchRest gen this is exposed as ‘bulk_save’). The first time I did this it worked fine and returned all the new id’s it created. After some thought about how to get the rest of my data in there I decided to use custom document IDs instead of the autogenerated UUIDs in couch assigns. Using the default id would mean I’d have to hit Couch to look up the id on each web service returned object just to get the document. This is an extra lookup in CouchDB which is fine because Couch is very fast but there’s no need for this.

CouchDB bulk create allows you to specify your own unique id to use instead of the auto assigned/generated one. In my situation this would allow me to just blindly post to Couch with my own ID in the URL and have the new data from my other queries go directly to the document. The progressive data enhancement I was after without the redundant lookup to get the right document first.

What I needed to do was wipe out my database that held the CouchDB created document with the CouchIDs, modify the hashes I get back from the web services to have “id”=>”myuniqueid” in there so when I did my bulksave CouchDB would not create IDs for me but just use the ones given to it.

Here’s (finally) where Ruby comes in.

Let’s say that here is the array of hashes I get back from the webservice:

vals =[{:a => "1"},{:a => "2"},{:a => "3"}]

(where :a is the key for the web service unique id value)

I need to modify each hash in this array to add {“id” => “valueof‘a’_”} so we want the first element to look like:

{"_id" => "1",:a => "1"}

for example…

Ruby #map to the rescue!

vals.map{|v| v["_id"]=v[:a]}

Gives us:

vals.inspect
=> "[{"_id"=>"1", :a=>"1"}, {"_id"=>"2", :a=>"2"}, {"_id"=>"3", :a=>"3"}]"

With our hash formatted the right way to use our web service given ID as the CouchDB ID bulk_save will create all the documents we need so that we can access them (using this sample data) like:

curl -X GET 'http://127.0.0.1:5984/test_db/1'

Should give you:

{"_id":"1","_rev":"1-10085f96b70ddbb6155710a391194304","a"=>"1"}

(your rev id will be different of course)

That’s all there is to it!

Today I set out to get one of my apps setup on the CI server we have use at work when I ran into this problem. It occurred only for a few of the remaining specs in the test suite that still use fixtures. The error looked something like this:

ActiveRecord::StatementInvalid in 'RegistryController should show the current registry for the current user - no params sent'
PGError: ERROR:  permission denied: "RI_ConstraintTrigger_2681229" is a system trigger: ALTER TABLE "schema_migrations" ENABLE TRIGGER ALL;ALTER TABLE "users" ENABLE TRIGGER ALL;ALTER
......
ALL;ALTER TABLE "master_answers" ENABLE TRIGGER ALL;ALTER TABLE "questions" ENABLE TRIGGER ALL;ALTER TABLE "answers" ENABLE TRIGGER ALL;ALTER TABLE "people" ENABLE TRIGGER ALL

Turns out this is a permission issue with the how Postgres handles triggers. Triggers belong to the superuser and if you’ve set up your DB permissions properly your test user on your DB should NOT be a super user.

This author correctly identifies the problem but suggests the solution is to change the permissions on your test user:

Here is a better approach to addressing the actual problem (and thorough explanation):

I deviated from this approach slightly in that I only added the ‘require’ statement to pull in the hack in my CI environment (not for all the environments as the author suggests). I thoughts are that this change only needs to solve a problem in the CI env, so that is where it should live. This could bite me in the butt because it introduces an inconsistency in the adapter behavior across envs. To be honest, I’m not sure which is worse. We’ll see how it plays out.