|
| 1 | +--- |
| 2 | +title: "Setup and configuration best practices" |
| 3 | +description: Best practices for seting up CodeRabbit. |
| 4 | +sidebar_label: Setup and configuration |
| 5 | +--- |
| 6 | + |
| 7 | +This page contains our best-practice advice for setting up CodeRabbit, and then |
| 8 | +configuring its code review behavior. |
| 9 | + |
| 10 | +## Setup best practices {#setup} |
| 11 | + |
| 12 | +This section lists our recommendations for setting up CodeRabbit with your |
| 13 | +Git platform, and integrating CodeRabbit with other tools and services. |
| 14 | + |
| 15 | +### Give CodeRabbit its own user account {#user} |
| 16 | + |
| 17 | +CodeRabbit works best when it has a user account all to itself on your Git platform. |
| 18 | +Your team treats this account as a bot or service account—even on platforms that don't |
| 19 | +have a formal concept of separate service accounts, such as Bitbucket Cloud. |
| 20 | + |
| 21 | +If you use GitHub, then CodeRabbit sets up a service account named `CoderabbitAI` 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. |
| 22 | + |
| 23 | +For platform-specific instructions about setting up this user, see |
| 24 | +[Integrate with Git platforms](/platforms/). |
| 25 | + |
| 26 | +### Let CodeRabbit read your issue tracker {#issues} |
| 27 | + |
| 28 | +CodeRabbit can report on whether the changes proposed by a pull request |
| 29 | +successfully address specific, ticketed issues referenced by that pull request. |
| 30 | + |
| 31 | +For this to work, CodeRabbit needs read access to your team's issue management system. |
| 32 | + |
| 33 | +If you use the built-in issue management of either GitHub or GitLab, then |
| 34 | +CodeRabbit issue integration works without any further setup. |
| 35 | + |
| 36 | +If you use issue management systems external from your Git platform, then you need to |
| 37 | +take additional steps to integrate CodeRabbit with your team's issues. |
| 38 | + |
| 39 | +These are the external issue management systems that CodeRabbit supports: |
| 40 | + |
| 41 | +- Jira |
| 42 | +- Linear |
| 43 | + |
| 44 | +For more information, see [Integrate issue tracking](/integrations/issue-integrations/). |
| 45 | + |
| 46 | +### Set up basic reports for your team {#reports} |
| 47 | + |
| 48 | +CodeRabbit has a flexible reporting feature that can help keep your whole team |
| 49 | +up-to-date about the latest changes to your repositories. We recommend setting |
| 50 | +up at least the following scheduled reports, using templates available |
| 51 | +through the CodeRabbit web interface: |
| 52 | + |
| 53 | +- A daily standup report, grouped by contributor. |
| 54 | +- Regular release notes, grouped by repository. |
| 55 | + |
| 56 | +For more information, see [Generate reports](/guides/reports-overview). |
| 57 | + |
| 58 | +## Configuration best practices {#configuration} |
| 59 | + |
| 60 | +This section lists our recommendations for configuring the way that CodeRabbit |
| 61 | +works with your individual repositories. |
| 62 | + |
| 63 | +### Fine-tune reviews using YAML files {#yaml} |
| 64 | + |
| 65 | +CodeRabbit gives you two ways to configure how it works with your team's repositories: |
| 66 | + |
| 67 | +- The [Repositories](https://app.coderabbit.ai/settings/repositories) page of the |
| 68 | + Dashboard |
| 69 | +- A [`coderabbit.yaml` file](/getting-started/configure-coderabbit/) in your repository |
| 70 | + |
| 71 | +The graphical UI of the Repositories page lets you set up your per-repository |
| 72 | +preferences more rapidly, and can help you get familiar with CodeRabbit configuration options. |
| 73 | + |
| 74 | +Once you are ready to fine-tune the ways that CodeRabbit works with your repositories, |
| 75 | +we recommend adding a `coderabbit.yaml` file to each one. This file has several |
| 76 | +advantages over using only the Dashboard: |
| 77 | + |
| 78 | +- It applies version control to your repository's CodeRabbit settings. |
| 79 | +- 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. |
| 80 | +- The file makes the repository's CodeRabbit settings transparent to all of the repository's contributors. |
| 81 | + |
| 82 | +Repository-level settings defined by a `coderabbit.yaml` take precedence over the |
| 83 | +settings defined for that repository in the Dashboard. |
| 84 | + |
| 85 | +For more information, see [Add a configuration file](/getting-started/configure-coderabbit/). |
| 86 | + |
| 87 | +### Speed up reviews by adding path filters {#filters} |
| 88 | + |
| 89 | +If your repository contains a lot of data or other content that CodeRabbit |
| 90 | +doesn't need for code review context, then you can include _path filters_ in |
| 91 | +your repository configuration. For example, a filter of `!dist/**` tells CodeRabbit |
| 92 | +to disregard everything in your reposistory's top-level `dist` directory when |
| 93 | +preparing a code review. |
| 94 | + |
| 95 | +Reducing the number of contextual files that CodeRabbit needs to read and analyze |
| 96 | +when preparing a code review can help make its code reviews faster. |
| 97 | + |
| 98 | +You can define path filters using the CodeRabbit |
| 99 | +web interface, or with [a configuration file](/getting-started/configure-coderabbit/). |
| 100 | + |
| 101 | +### Trust the defaults {#defaults} |
| 102 | + |
| 103 | +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: |
| 104 | + |
| 105 | +- **Cache**: Keep [the cache](/reference/caching) enabled to let CodeRabbit temporarily remember details about your repository |
| 106 | + between reviews, which improves review speed. |
| 107 | +- **Tools**: By default, CodeRabbit is allowed to use all of the [open-source linters and analyzer |
| 108 | + tools](/tools) that are available to it during code reviews. This helps CodeRabbit keep its reviews broad and flexible. |
| 109 | +- **Knowledge base**: CodeRabbit [knowledge base](/integrations/knowledge-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. |
| 110 | + |
| 111 | +You can configure your use of the above features using the CodeRabbit web interface, or [a configuration file](/getting-started/configure-coderabbit/). |
| 112 | + |
| 113 | +### Write specific CI/CD error messages {#pipeline} |
| 114 | + |
| 115 | +CodeRabbit can analyze the logs of continuous integration (CI) or continuous |
| 116 | +deployment (CD) tools in your pipeline. CodeRabbit can provide better remediation |
| 117 | +advice about CI/CD failures during code reviews if your tools' error messages |
| 118 | +are as specific as possible when reporting failures. |
| 119 | + |
| 120 | +For CodeRabbit to provide the best advice, configure your CI/CD failure output to include the following information: |
| 121 | + |
| 122 | +- File names associated with the failure. |
| 123 | +- Line numbers that identify where the failure occurred in those files. |
| 124 | +- An explanation of the failure, including relevant error codes or diffs. |
| 125 | + |
| 126 | +[This pull request](https://github.com/ff14-advanced-market-search/temp-fe/pull/47/files) shows an example of expanding the context of a CI error, |
| 127 | +in this case including a diff to show why a code-formatter check failed. |
| 128 | + |
| 129 | +--- |
| 130 | + |
| 131 | +## What's next {#whats-next} |
| 132 | + |
| 133 | +- [Code review best practices](/guides/code-review-best-practices) |
0 commit comments