Group

Configuring your reviews

Reviews can be configured for each repository through a .ebert.yml file on the root of your repository. Through this file you can configure which static analysis engines should be used for the review, which paths shouldn't be reviewed, have a fine grain control of how Pull Requests should be reviewed and more.

Engines

It is possible to configure which engines should be used for the repository review under the engines key. For instance, to enable the RuboCop and SCSS Lint engines to review your project, add the following to your .ebert.yml.

engines:
  rubocop:
    enabled: true
  scss-lint:
    enabled: true

Engines that aren't present under the engines section or have an enabled: false property won't be executed during the repository's reviews.

engines:
  rubocop:
    enabled: false # RuboCop is now disabled and won't be used for future reviews.
  scss-lint:
    enabled: true

Some engines have extra configuration settings that can be set under their engines entry, like the fixme and duplication engines, but for engines that are based on existing tools (like RuboCop, SCSS Lint, ESLint and others), we recommend using the engine specific configuration file (.rubocop.yml, .scss-lint.yml or .eslintrc, respectively), that way your configuration isn't tied to Ebert's configuration file and you will still be able to run each engine manually or through a text editor's plugin.

Excluding paths

You can exclude specific paths (files, directories or glob expressions) from your reviews on the exclude_paths section.

# 'engines' section omitted.

exclude_paths:
- lib/generators/**/*.tt
- config
- test

We recommend developers to exclude test specific files (usually located under test or spec), configuration specific files, directories with 3rd party assets and compilation artifacts (for instance, when using transpilers like CoffeeScript or Babel while keeping the final JavaScript files in the repository).

If you want to exclude paths for a specific engine, you can set the exclude_paths section inside that engine's entry on your engines section.

Let's say we want to exclude all files under app/views from the duplication engine, but not from RuboCop. We can do the following on our ebert.yml file.

engines:
  rubocop:
    enabled: true
  duplication:
    enabled: true
    exclude_paths:
      - app/views/**/*
exclude_paths:
- lib/generators/**/*.tt
- config
- test

Pull Requests

Ebert will review all your Pull Requests by default, but you can tweak this configuration if necessary.

You can disable all Pull Request reviews by setting the enabled property of the pull_requests section to false.

pull_requests:
  enabled: false

If you want to review only the Pull Requests of a specific set of GitHub users - useful if you want to gradually adopt the automatic reviews to your process - you can set an Array of authors with the usernames of those you want their Pull Requests to be reviewed.

pull_requests:
  authors:
    - huey
    - dewey
    - louie

With this config, Pull Requests from @huey, @dewey and @louie will be reviewed, while Pull Requests from other GitHub users will be skipped.

Disabling comments

If you want, you can disable the "inline" comments from the reviews of your Pull Requests and configure Ebert to only create/update the summary comment on your Pull Request. You can use the comments: false property for that.

pull_requests:
  comments: false

Sub applications

Ebert has support for reviewing repositories that contain different applications distributed over different directories, which we call Sub applications. Under the subapps key you can set a list of paths and names for each application that is contained under the repository, and Ebert will perform the review separately for each existing application.

For instance, a repository that include a Rails application under the backend directory and an Ember client app on client can be configured as the following:

subapps:
  - name: 'Backend Application'
    path: 'backend'

  - name: 'Ember Front end'
    path: 'client'

Styleguide repository

Each of the static analysis engines we support has a specific way that you can configure it through configuration files inside your repository, and Ebert uses a default set of curated configurations when reviewing your repository that's located on the plataformatec/linters GitHub repository.

If you want to pull these configurations from a different repository - from your own Styleguide repository - you can set the owner and repository name on the styleguide key:

styleguide: acme-co/ebert-configs
# ...

Also, if you want to use a different ref other than master, you can set it at the end of the styleguide key:

styleguide: acme-co/ebert-configs#branch-name
# ...

For instance, when running RuboCop, Ebert will download the .rubocop.yml configuration file from the acme-co/ebert-configs GitHub repository and use it to perform the review. This configuration can be useful to ensure a organization-wide consistent configuration and maintain all of your configuration files in one place.

If you want, you can opt out of our default styleguide by setting the styleguide key as false.

# Do not use the plataformatec/linters configurations on my reviews.
styleguide: false
# ...

Automatic configuration

For repositories that don't have an .ebert.yml file, Ebert will generate a configuration that suits the directory structure and code found in the repository, ignoring known directories (like test, spec, public or vendor) and enabling recommended engines for your project. After the review is finished you can download the respective .ebert.yml file from the review's page.

Other settings

Additional settings can be configured directly through Ebert web interface, and they will be applied to all repositories inside your account. From your dashboard, click on the Review settings link below the name of the account for which you want to configure your reviews to see all the available account wide settings.

These settings can be updated any time and will be applied for any future reviews, without requiring you to change the contents of the .ebert.yml files in your repositories and push them to your upstream repositories.

Need more help? Feel free to contact us via email or chat.