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
engines: rubocop: enabled: true scss-lint: enabled: true
Engines that aren’t present under the
engines section or have an
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
entry, like the
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 (
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
You can exclude specific paths (files, directories or glob expressions) from your
reviews on the
# 'engines' section omitted. exclude_paths: - lib/generators/**/*.tt - config - test
We recommend developers to exclude test specific files (usually located under
spec), configuration specific files, directories with 3rd party assets and
compilation artifacts (for instance, when using transpilers like CoffeeScript or Babel
If you want to exclude paths for a specific engine, you can set the
section inside that engine’s entry on your
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
engines: rubocop: enabled: true duplication: enabled: true exclude_paths: - app/views/**/* exclude_paths: - lib/generators/**/*.tt - config - test
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
pull_requests section to
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
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
@louie will be
reviewed, while Pull Requests from other GitHub users will be skipped.
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
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
directory and an Ember client app on
client can be configured as the
subapps: - name: 'Backend Application' path: 'backend' - name: 'Ember Front end' path: 'client'
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: 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: 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
# Do not use the plataformatec/linters configurations on my reviews. styleguide: false # ...
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
enabling recommended engines for your project. After the review is finished you
can download the respective
.ebert.yml file from the review’s page.
A channel defines which version of an engine will be used to run checks for your code.
By default Ebert will use
stable channel, that is our recommendation for using that check,
to use you don’t need to specify anything in your configuration.
In case you want to use a different version you can specify the channel for each engine with the following in your configuration file:
engines: rubocop: enabled: true channel: rubocop-0-49
In the example above we’re using
rubocop-0-49 channel for
rubocop engine. In
engine details page you can check which channels are available to use in your configuration file.
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.