New project type: Ruby
Bitrise now supports Ruby as a project type. When you add a Ruby repository, the project scanner analyses your codebase and generates a ready-to-run test workflow — with the hope to minimise any YAML editing to get your first green build.
This isn’t a one-size-fits-all template. The scanner reads multiple signals from your repository and assembles a workflow that matches your specific project setup.
At a glance
| What’s detected | How |
|---|---|
| Rails | rails gem in Gemfile |
| Databases | pg, mysql2, redis, mongoid/mongo, sqlite3 in Gemfile |
| Test framework | RSpec (spec/spec_helper.rb, .rspec), Minitest (test/test_helper.rb), or Rake fallback |
| Bundler | Gemfile.lock present |
| Ruby version | .ruby-version or .tool-versions (asdf) |
| DB connection details | config/database.yml, config/mongoid.yml (ERB resolved) |
| Monorepo projects | In a repository with multiple Ruby projects, each project is detected and scanned independently. You can select and configure one of the detected projects. |
| What’s generated | When |
|---|---|
| Git clone + SSH key | Always |
| Gem cache (restore & save) | Always |
bundle install |
Gemfile.lock detected |
System dependencies (libmariadb-dev) |
mysql2 gem detected |
Database setup (db:create db:schema:load) |
Relational DB gem detected |
| Service containers (Postgres, MySQL, Redis, MongoDB) | Corresponding gem detected |
| Test step | Test framework or Rakefile detected |
How the scanner reads your project
The starting point is your Gemfile. The scanner checks which gems are declared to understand what kind of Ruby project you’re working with — whether it’s a Rails application, a plain Ruby project, or something in between. It detects database gems (pg, mysql2, redis, mongoid/mongo, and sqlite3) and whether the rails gem is present.
Beyond the Gemfile, the scanner inspects the filesystem for additional signals: whether a Gemfile.lock exists (Bundler), whether there’s a Rakefile, and which test framework you’re using. It detects RSpec by looking for spec/spec_helper.rb or .rspec, and Minitest by looking for test/test_helper.rb. If neither is found but a Rakefile is present, it falls back to rake test.
The scanner also reads your .ruby-version or .tool-versions file (asdf format) to pin the correct Ruby version for your builds.
Smart database configuration
One of the things we’re most pleased with is the database detection. It goes beyond simply spotting a gem name in your Gemfile.
For each detected database gem, the scanner generates the appropriate service container — Postgres, MySQL, Redis, or MongoDB — with the correct image, port mapping, and health checks so the container is fully ready before your tests try to connect.
But it goes further. The scanner parses your config/database.yml (for relational databases) and config/mongoid.yml (for MongoDB) to extract connection details. It resolves ERB expressions — so if your database.yml contains something like ENV.fetch("DB_HOST", "localhost"), the scanner picks up both the environment variable name and its default value. These are then set as app-level environment variables in your Bitrise configuration, which means your test workflow connects to the service containers without any manual environment setup.
The scanner prefers the test environment section in your database.yml, falling back to default if a test block isn’t present — which is exactly the lookup order Rails itself uses.
The right test command for your setup
The generated test step isn’t just “run the tests”. The scanner picks the right command based on what it finds:
- RSpec →
bundle exec rspec(optional in each test command, used only if Bundler is detected.) - Minitest in a Rails project →
bundle exec rails test - Minitest with a Rakefile (non-Rails) →
bundle exec rake test - Minitest without Rails or Rakefile →
bundle exec ruby -Itest test/**/*_test.rb - No test framework but a Rakefile exists →
bundle exec rake test
This means the workflow does the right thing whether you’re on a conventional Rails app or a standalone Ruby project with its own test structure.
Monorepo support
If your repository contains multiple Ruby projects in different directories — each with its own Gemfile — the scanner detects each one separately, and lets the user select and configures one of those projects. The working directory is set appropriately so dependencies and tests run in the right context.
Getting started
Add a new app on Bitrise and point it at a repository containing a Gemfile. The scanner handles the rest.
If you’d prefer to start from a generic template — or if you’re not using the scanner — you can select Ruby as your project type manually. The default manual configuration assumes Bundler and RSpec with no database, giving you a clean starting point to customise.
We’d love to hear how it works with your Ruby projects. If you run into anything unexpected, let us know in the comments.