This page contains our best-practice advice for setting up CodeRabbit, and thenconfiguring its code review behavior.

Setup best practices​

This section lists our recommendations for setting up CodeRabbit with yourGit platform, and integrating CodeRabbit with other tools and services.

Give CodeRabbit its own user account​

CodeRabbit works best when it has a user account all to itself on your Git platform.Your team treats this account as a bot or service account—even on platforms that don'thave a formal concept of separate service accounts, such as Bitbucket Cloud.

If you use GitHub, then CodeRabbit sets up a service account namedCodeRabbitAI for you as soon as you connect your GitHub organization to CodeRabbit. On other platforms, such as Bitbucket Cloud or Gitlab, you must set this account up yourself.

For platform-specific instructions about setting up this user, seeIntegrate with Git platforms.

Let CodeRabbit read your issue tracker​

CodeRabbit can report on whether the changes proposed by a pull requestsuccessfully address specific, ticketed issues referenced by that pull request.

For this to work, CodeRabbit needs read access to your team's issue management system.

If you use the built-in issue management of either GitHub or GitLab, thenCodeRabbit issue integration works without any further setup.

If you use issue management systems external from your Git platform, then you need totake additional steps to integrate CodeRabbit with your team's issues.

These are the external issue management systems that CodeRabbit supports:

• Jira
• Linear

For more information, seeIntegrate issue tracking.

Set up basic reports for your team​

CodeRabbit has a flexible reporting feature that can help keep your whole teamup-to-date about the latest changes to your repositories. We recommend settingup at least the following scheduled reports, using templates availablethrough the CodeRabbit web interface:

• A daily standup report, grouped by contributor.
• Regular release notes, grouped by repository.

For more information, seeGenerate reports.

Configuration best practices​

This section lists our recommendations for configuring the way that CodeRabbitworks with your individual repositories.

Fine-tune reviews using YAML files​

CodeRabbit gives you two ways to configure how it works with your team's repositories:

• TheOrganization Settings andRepositories pages oftheCodeRabbit web interface
• A.coderabbit.yaml file in your repository

The web interface lets you set up your organization's code reviewpreferences rapidly, and can help you get familiar with CodeRabbit configuration options.

We recommend adding a.coderabbit.yaml file to repositories, as well. Using this file has several advantages over using only the web interface:

• It applies version control to your repository's CodeRabbit settings, letting you track changes, view configuration history, and revert to previous configurations as needed.
• During code reviews, CodeRabbit loads the file along with rest of your repository. This means that you can include setting changes as part of a pull request, and CodeRabbit both analyzes and applies these settings during its review.
• The file makes the repository's CodeRabbit settings transparent to all of the repository's contributors.

Repository-level settings defined by a.coderabbit.yaml take precedence over thesettings defined for that repository or for your organization using the CodeRabbit web interface.

For more information, seeAdd a configuration file.

Speed up reviews by adding path filters​

If your repository contains a lot of data or other content that CodeRabbitdoesn't need for code review context, then you can includepath filters inyour repository configuration. For example, a filter of!dist/** tells CodeRabbitto disregard everything in your repository's top-leveldist directory whenpreparing a code review.

Reducing the number of contextual files that CodeRabbit needs to read and analyzewhen preparing a code review can help make its code reviews faster.

You can define path filters using the CodeRabbitweb interface, or witha.coderabbit.yaml file.

Trust the defaults​

CodeRabbit gives you control over a number of its core code-review features, letting you deactivate them entirely for your repositories if needed. We have chosen the default settings to meet the needs of most organizations and situations, and recommend leaving these settings at their default values if possible:

• Cache: Keepthe cache enabled to let CodeRabbit temporarily remember details about your repositorybetween reviews, which improves review speed.
• Tools: By default, CodeRabbit is allowed to use all of theopen-source linters and analyzertools that are available to it during code reviews. This helps CodeRabbit keep its reviews broad and flexible.
• Knowledge base: CodeRabbitknowledge base features, including learnings and issue tracking, can require data retention. If your organization needs to meet stricter data-retention policies, then you can opt out of using these features.

You can configure your use of the above features using the CodeRabbit web interface, ora.coderabbit.yaml file.

Write specific CI/CD error messages​

CodeRabbit can analyze the logs of continuous integration (CI) or continuousdeployment (CD) tools in your pipeline. CodeRabbit can provide better remediationadvice about CI/CD failures during code reviews if your tools' error messagesare as specific as possible when reporting failures.

For CodeRabbit to provide the best advice, configure your CI/CD failure output to include the following information:

• File names associated with the failure.
• Line numbers that identify where the failure occurred in those files.
• An explanation of the failure, including relevant error codes or diffs.

This pull request shows an example of expanding the context of a CI error,in this case including a diff to show why a code-formatter check failed.

What's next​

• Code review best practices