Travis CI is a popular service for continuous integration, allowing you to run test suites, perform builds, and even deploy to servers in an automated fashion.

RBCommons can integrate with Travis CI to do test builds of code changes and report the results back as a status update on the review request.

You can have multiple different Travis CI configurations (up to your plan limit), in the case where you may need to have review requests on different repositories use different Travis CI configurations.

Integration Configuration

  1. In your Team Administration page, navigate to Integrations and click Add Integration -> Travis CI.

  2. Provide a descriptive name in the Name field.
  3. Configure the Conditions in which a build will be triggered.

    At a minimum, you should set a condition to match a specific repository. Even if you only have one repository configured now, you’ll want to set this up so things don’t break if you connect a second one. If needed, you can create complex rules for which review requests get matched with this config (for example, if you only want to run a test suite for certain branches).

    If you want to trigger builds for all code changes, this can be set to Always match.

  4. Optionally, specify the Build Config as a replacement for the repository’s .travis.yml file.

    This should define an isolated build configuration that lacks any deployment or notification steps. The required steps for building the patch and reporting results back to RBCommons will be automatically included when the build is triggered.

    Warning: This configuration should not include any secrets, since code submitted through RBCommons will have access to the decrypted data (and these secrets are not needed when there is no deployment or notification).

    language: python
    python: 2.7
        - python develop
        - pip install -r dev-requirements.txt
        - python ./tests/
  5. Optionally, specify a Build Branch. By default, the Travis CI user interface will show all builds as occurring on master. This field allows you to override the branch name to be something else, as to separate review request builds from regular builds.

    Note: We recommend creating and pushing a dummy branch named “review-requests” to your repository, and then filling in that name here. The actual contents of that branch are unimportant, and it never needs to be updated, since the source will be completely replaced during the build process.

If at any point you want to stop triggering builds but do not want to delete the configuration, you can uncheck Enable this integration.