General Support

Language Integrations

Coveralls API

Open an Issue

Coveralls Currently Supports These CIs

Currently, Coveralls officially supports:


This configuration guide is specifically for the Ruby language. Other language support can be found in the individual READMEs.

Coveralls for Ruby uses an optional .coveralls.yml file at the root level of your repository to configure options. Note: public Travis-CI repos do not need this config file since Coveralls can get the information via their API (using access token exchange).

The option repo_token (found on your repository’s page on Coveralls) is used to specify which project on Coveralls your project maps to. This is only needed for private repos and should be kept secret – anyone could use it to submit coverage data on your repo’s behalf.

Another important option is service_name which allows you to specify where Coveralls should look to find additional information about your builds. This can be any string, but using travis-ci or travis-pro will allow Coveralls to fetch branch data, comment on pull requests, and more.

A .coveralls.yml file configured for Travis Pro:

service_name: travis-pro
repo_token: ...


When using these CI’s you must either include your repo token in a .coveralls.yml file or, if you don’t want it under source control, set it in your build config like this in the “Test Commands” (CircleCI) or “Build Commands” (Semaphore) section of the project settings:

COVERALLS_REPO_TOKEN=asdfasdf bundle exec rspec spec


To receive PR status updates from Jenkins you’ll need to install this plugin: Github Pull Request Builder and then add this environment variable at build time:



Setup info graciously provided by Collin Allen.

(This was done on Bamboo 4.4.3 which is only a few point releases behind current)

In the Bamboo Plan, add a new source repository of type Git (or GitHub – either will work). You just want to get the code from GitHub checked out to the Bamboo build agent. If you’re using Bamboo already, it’s likely this is already in place.

In the default job for that plan, add a Source Code Checkout task, set to pull from the repository set up at the plan level (above). This will check out the code on the agent that is performing the build.

Add a second task to the job, a Script task. For the script body, enter:

bundle exec rspec spec

And in the Environment Variables field for the script, enter the following (replacing yourrepotoken with your Coveralls repo token from when you linked the GitHub repo):

CI_NAME=bamboo CI_BUILD_NUMBER="${bamboo.buildNumber}" CI_BUILD_URL="${bamboo.buildResultsUrl}" CI_BRANCH="${bamboo.repository.git.branch}" COVERALLS_REPO_TOKEN=yourrepotoken CI=true

That’s it! Run a Bamboo build, and the “bundle exec rspec spec” will perform the tests, and the necessary environment variables will get populated by Bamboo and picked up by the Coveralls gem.

(You could alternatively define “bundle” as an executable for the Bamboo agent and use a Command task instead of a Script task, but in both cases, the key is to make sure those environment variables are set at the time the tests get run. You could also add the coveralls repo token as a Bamboo plan variable with “password” in the name so that it will be obscured in the logs.)


It’s easy to support Coveralls on your CI server, all that’s needed are these environment variables to be available at build time:

CI_PULL_REQUEST (optional)