CircleCI Integration¶

Integration Configuration¶

To configure integration with CircleCI, click Add a new configuration on the Integrations page in the Administration UI. You can have multiple different CircleCI configurations, in the case where you may need to have review requests on different repositories use different CircleCI API keys.

In the configuration, there are several required fields.

The Name field can be used to set a name for this particular configuration. This allows you to keep track of which is which in the case where you have multiple CircleCI configurations.

Conditions allows you to set conditions for when Review Board will trigger a build. If you want to trigger builds for all code changes, this can be set to Always match. However, you can also create complex rules for which review requests will match. Because CircleCI only works with GitHub and Bitbucket repositories, only changes on repositories configured with those hosting services will trigger builds.

API Token should be set to a valid CircleCI API Token. These can be created by going to CircleCI and selecting User Settings from the menu at the top right. From there, select Personal API Tokens.

There’s one additional optional field, Build Branch. By default, the CircleCI 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.

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

CircleCI config.yml Configuration¶

CircleCI has no built-in support for doing test builds of patches, so Review Board will trigger a build using a special job name and pass in information in the environment which will allow you to set up the build using .circleci/config.yml.

There are several environment variables which will be passed in to your build:

• REVIEWBOARD_SERVER - The Review Board server name.

• REVIEWBOARD_REVIEW_REQUEST - The ID of the review request.

• REVIEWBOARD_DIFF_REVISION - The revision of the diff to build.

• REVIEWBOARD_API_TOKEN - An API token to use when communicating with Review Board.

• REVIEWBOARD_STATUS_UPDATE_ID - An internal identifier used when reporting status back to the Review Board server.

In order for builds with Review Board to work, the .circleci/config.yml file must define a job named reviewboard, and a webhook notification. The job should look substantially similar to your normal build job, but with the addition of a step at the beginning to apply the patch from Review Board. This should also not include anything that you don’t want to run on uncommitted changes, such as deployments.

This is an example .circleci/config.yml file which sets up a Python 2.7 environment, installs dependencies, and runs a unit test script. As you can see, the steps for the reviewboard job are virtually identical to the build job, except there’s an extra one at the start which applies the patch using rbt patch.

jobs:
  build:
    docker:
      - image: circleci/python:2.7
    steps:
      - checkout
      - run:
        name: Install dependencies
        command: sudo python setup.py develop
      - run:
        name: Run tests
        command: python ./tests/runtests.py
  reviewboard:
    docker:
      - image: circleci/python:2.7
    steps:
      - checkout
      - run:
        name: Apply patch
        command: |
          sudo pip install rbtools
          rbt patch --api-token "$REVIEWBOARD_API_TOKEN" --server "$REVIEWBOARD_SERVER" --diff-revision "$REVIEWBOARD_DIFF_REVISION" "$REVIEWBOARD_REVIEW_REQUEST"
      - run:
        name: Install dependencies
        command: sudo python setup.py develop
      - run:
        name: Run tests
        command: python ./tests/runtests.py
notify:
  webhooks:
    - url: https://reviewboard.example.com/rbintegrations/circle-ci/webhook/