Continuous Integration and Continuous Deployment with Ruby/Rails
CircleCI makes Rails testing simple. During each build, Circle looks at your code, infers your build environment, and runs your tests. The majority of the time, this just works—and works well. Of course, it helps if your project adheres to standard practices (i.e., “convention over configuration”) for standard Ruby testing frameworks.
If you don’t want to use the default, you can specify your version in
machine: ruby: version: 2.4.0
In the current version of CircleCI, we use RVM to manage and install different versions of Ruby. This has a couple of side-effects:
First, if the version specified in
circle.yml isn’t available then
rvm will try to install it. If RVM cannot find a pre-compiled binary from available mirrors, it will download and compiled from source. Since fetching the binary from several possible mirrors is prone to failure caused by unstable networks, we highly recommend caching this file. To do this, please read our Discuss guide on how to cache a pre-compiled Ruby binary to improve build performance/reliability.
Second, whenever the build changes into your project directory, RVM will try to read either
.ruby-version via the
cd auto hook. To avoid this and the aforementioned behavior, we recommend removing these files by running:
If RVM insists on installing certain versions, you can configure RVM to not install Ruby versions that don’t exist on the system:
echo 'export rvm_install_on_use_flag=0' >> /home/ubuntu/.rvmrc
If Circle detects a Gemfile, we automatically run
bundle install. Your
gems are automatically cached between builds to save time downloading dependencies.
You can add additional project dependencies from the
dependencies section of your circle.yml:
dependencies: post: - bundle exec rake assets:precompile
The default inferred step for Bundler is
bundle check || bundle install. For reasons, we use
check prior to
install in order to skip unnecessary steps inherited from the
bundle install command when all depedencies are cached or otherwise already installed and available on the system.
Circle manages all your database requirements,
such as running your
rake commands for creating, loading,
and migrating your database.
We have pre-installed more than a dozen databases and queues,
including PostgreSQL, MySQL, and MongoDB.
You can add custom database commands from the
database section of your circle.yml.
Circle will automatically infer your test commands if you’re using Test::Unit, RSpec, Cucumber, Spinach, Jasmine, or Konacha. You can also add additional commands from the test section of your circle.yml:
test: post: - bundle exec rake test:custom
Testing in Parallel
Should you need faster testing, Circle can automatically split your tests and run them in parallel across multiple machines. You can enable parallelism on your project’s Project Settings > Parallelism page in the Circle UI.
Circle can automatically split tests for RSpec, Cucumber, and Test::Unit. For other testing libraries, we have instructions for manually setting up parallelism.
Circle offers first-class support for deployment to your staging and production environments. When your build is green, Circle will run the commands from the deployment section of your circle.yml.
You can find more detailed instructions in the Continuous Deployment doc.
Troubleshooting for Ruby on Rails
Our Ruby troubleshooting documentation has information about the following issues and problems:
- Do you need the latest version of Bundler?
- RSpec is failing but CircleCI reports my tests have passed
- The Ruby debugger gem won’t build
- “unable to obtain stable firefox connection in 60 seconds”
- Git errors during a bundle install
- rake db:schema:load fails
- CircleCI is running the Ruby commands not specified in the config
- CircleCI uses the wrong Ruby version