Coveralls currently supports

Currently, Coveralls officially supports:

Configuration

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: ...

Circle, Jenkins, Semaphore and Codeship

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

Jenkins Pull Request Support

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:

CI_PULL_REQUEST=$ghprbPullId

Atlassian Bamboo

Setup info graciously provided by Collin Allen.

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

  1. In the Bamboo Plan, add a new source respository 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.
  2. 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.
  3. 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 coveralls.io 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.)

Insert your CI here

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_NAME
CI_BUILD_NUMBER
CI_BUILD_URL
CI_BRANCH
CI_PULL_REQUEST (optional)
Have more questions? Submit a request

Comments

Powered by Zendesk