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

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.

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:

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.