Genuity Tech Blog

Tidbits of Ruby, Rails, and all things related

Heroku Labs and user_env_compile

TL;DR

Heroku Lab’s user_env_compile feature reveals your app’s config vars at slug compile time. You have to first install the Heroku Labs plugin. Then enable the user_env_compile feature.



In case you missed it, Heroku recently announced the new Heroku Labs. As described in their email:

Heroku Labs gives you granular control over your use of experimental Heroku features. You can choose to turn individual features on and off as you need them.

One of the first features they rolled out, and one that’s of particular interest to me, is their user_env_compile feature. Enabling this feature will make your app’s config vars available at slug compile time. “Why is this important?”, you might ask? Well, one reason is if you are using the asset pipeline introduced in Rails 3.1.

Pre-compiling assets and the Rails environment

When you push your app to the heroku remote, Heroku will try to pre-compile your assets by running rake assets:precompile. When that happens, your Rails environment is loaded. This in part means that your initializers under config/initializers/ are ran. If you have any code in one of those initializers that accesses the database, your Heroku app will need to have access to the DATABASE_URL config var.

Before the user_env_compile feature, your config vars weren’t available at slug compile time, and Heroku would execute rake assets:precompile with a fake DATABASE_URL var. When your initializer tried to access the database via that fake value, you would see an error similar to this:

1
2
3
could not connect to server: Connection refused
Is the server running on host "127.0.0.1" and accepting
TCP/IP connections on port xxxx?

You would also see this in the output:

1
Precompiling assets failed, enabling runtime asset compilation

This isn’t exactly ideal, because now the first request to your app would trigger the asset compilation. That first user would have to wait for how ever many seconds it takes to compile them before they could see your awesome site!

Heroku Labs to the rescue!

We can fix all of our problems by using Heroku Labs, and the user_env_compile feature. First, install the heroku-labs plugin:

1
$ heroku plugins:install http://github.com/heroku/heroku-labs.git

Now, enable the user_env_compile feature:

1
2
3
$ heroku labs:enable user_env_compile -a myapp
-----> Enabling user_env_compile for myapp... done
WARNING: This feature is experimental and may change or be removed without notice.

Now, the next time you push to the heroku remote, asset pre-compilation won’t fail due to database inaccessability.

One other step that was necessary in the past was to set config.assets.initialize_on_precompile = false in config/application.rb. This would help with asset pre-compilation in certain situations, but didn’t cure them all. This is no longer necessary with the user_env_compile feature either. Feel free to clean up config/application.rb by removing this line.

More Info

To get more info on the user_env_compile feature, you can read the official docs. For more info on Heroku Labs, that info is here.

I’m looking forward to more features released through Heroku Labs. Maybe they will finally implement multiple app owners!

Comments