|
| 1 | +# .coderabbit.yaml |
| 2 | +language: en |
| 3 | +early_access: true |
| 4 | +enable_free_tier: true |
| 5 | +reviews: |
| 6 | + enabled: true |
| 7 | + profile: chill |
| 8 | + instructions: >- |
| 9 | + # Code Review Instructions |
| 10 | +
|
| 11 | + - Ensure the code follows best practices and coding standards. |
| 12 | + - For **Python** code, follow |
| 13 | + [PEP 20](https://www.python.org/dev/peps/pep-0020/) and |
| 14 | + [CEP-8](https://gist.github.com/reactive-firewall/b7ee98df9e636a51806e62ef9c4ab161) |
| 15 | + standards. |
| 16 | + - For **BASH** and **Shellscript** code, follow |
| 17 | + [Pure BASH Bible](https://github.com/dylanaraps/pure-bash-bible) and |
| 18 | + [CEP-5](https://gist.github.com/reactive-firewall/3d2bd3cf37f87974df6f7bee31a05a89) |
| 19 | + standards. |
| 20 | + - Check all **BASH** files start with an |
| 21 | + [extensive disclaimer](https://gist.github.com/reactive-firewall/866b42d175ae3ebefcb2a5878b30ea17). |
| 22 | + - Check for security vulnerabilities and potential issues. |
| 23 | + - Ensure the code follows the **DRY, AHA, and SOLID** principles. |
| 24 | +
|
| 25 | + # Documentation Review Instructions |
| 26 | + - Verify that documentation and comments are clear and comprehensive. |
| 27 | + - Verify that documentation and comments are free of spelling mistakes. |
| 28 | + - Verify that technical documentation includes a "References" section at |
| 29 | + the end of documentation, using the same format as actual RFCs, with |
| 30 | + both "Normative References" and "Informative References". |
| 31 | +
|
| 32 | + # Test Code Review Instructions |
| 33 | + - Ensure that test code is automated, comprehensive, and follows testing best practices. |
| 34 | + - Verify that all critical functionality is covered by tests. |
| 35 | + - Ensure that test code follow |
| 36 | + [CEP-8](https://gist.github.com/reactive-firewall/d840ee9990e65f302ce2a8d78ebe73f6) |
| 37 | +
|
| 38 | + # Misc. |
| 39 | + - Confirm that the code meets the project's requirements and objectives. |
| 40 | + - Confirm that copyright years are up-to date whenever a file is changed. |
| 41 | + request_changes_workflow: true |
| 42 | + high_level_summary: true |
| 43 | + high_level_summary_placeholder: '@coderabbitai summary' |
| 44 | + auto_title_placeholder: '@coderabbitai' |
| 45 | + review_status: true |
| 46 | + poem: true |
| 47 | + collapse_walkthrough: false |
| 48 | + sequence_diagrams: true |
| 49 | + changed_files_summary: true |
| 50 | + labeling_instructions: |
| 51 | + - label: Python Lang |
| 52 | + instructions: Apply when the PR/MR contains changes to python source-code. |
| 53 | + - label: Bash Lang |
| 54 | + instructions: >- |
| 55 | + Apply when the PR/MR contains changes to shell-scripts or BASH code |
| 56 | + snippets. |
| 57 | + - label: Make Lang |
| 58 | + instructions: >- |
| 59 | + Apply when the PR/MR contains changes to the file `Makefile` or makefile |
| 60 | + code snippets. |
| 61 | + - label: Documentation |
| 62 | + instructions: >- |
| 63 | + Apply whenever project documentation (namely markdown source-code) is |
| 64 | + updated by the PR/MR. Also apply when PR contains a commit with a commit |
| 65 | + message prefixed with "[DOCUMENTATION] " |
| 66 | + - label: Linter |
| 67 | + instructions: >- |
| 68 | + Apply when the purpose of the PR/MR is related to fixing the feedback |
| 69 | + from a linter. Also apply if suggested fixes are used and improve the |
| 70 | + code's compliance with the PEP-8 standard. |
| 71 | + path_filters: ['!*.xc*/**', '!node_modules/**', '!dist/**', '!build/**', '!.git/**', '!venv/**', '!__pycache__/**'] |
| 72 | + path_instructions: |
| 73 | + - path: README.md |
| 74 | + instructions: >- |
| 75 | + 1. Consider the file 'README.md' the overview/introduction of the project. |
| 76 | + Also consider the 'README.md' file the first place to look for project documentation. |
| 77 | +
|
| 78 | + 2. When reviewing the file 'README.md' it should be linted with help |
| 79 | + from the tools `markdownlint` and `languagetool`, pointing out any issues. |
| 80 | +
|
| 81 | + 3. You may assume the file 'README.md' will contain GitHub flavor Markdown. |
| 82 | + - path: '**/*.py' |
| 83 | + instructions: >- |
| 84 | + When reviewing Python code for this project: |
| 85 | +
|
| 86 | + 1. Prioritize portability over clarity, especially when dealing with cross-Python compatibility. However, with the priority in mind, do still consider improvements to clarity when relevant. |
| 87 | +
|
| 88 | + 2. As a general guideline, consider the code style advocated in the PEP 8 standard (excluding the use of spaces for indentation) and evaluate suggested changes for code style compliance. |
| 89 | +
|
| 90 | + 3. As a style convention, consider the code style advocated in [CEP-8](https://gist.github.com/reactive-firewall/b7ee98df9e636a51806e62ef9c4ab161) and evaluate suggested changes for code style compliance. |
| 91 | +
|
| 92 | + 4. As a general guideline, try to provide any relevant, official, and supporting documentation links to any tool's suggestions in review comments. This guideline is important for posterity. |
| 93 | +
|
| 94 | + 5. As a general rule, undocumented function definitions and class definitions in the project's Python code are assumed incomplete. Please consider suggesting a short summary of the code for any of these incomplete definitions as docstrings when reviewing. |
| 95 | +
|
| 96 | + 6. Verify Flake8's configuration file is located at ".flake8.ini" |
| 97 | + - path: tests/* |
| 98 | + instructions: >- |
| 99 | + When reviewing test code: |
| 100 | +
|
| 101 | + 1. Prioritize portability over clarity, especially when dealing with cross-Python compatibility. However, with the priority in mind, do still consider improvements to clarity when relevant. |
| 102 | +
|
| 103 | + 2. As a general guideline, consider the code style advocated in the PEP 8 standard (excluding the use of spaces for indentation) and evaluate suggested changes for code style compliance. |
| 104 | +
|
| 105 | + 3. As a style convention, consider the code style advocated in [CEP-8](https://gist.github.com/reactive-firewall/b7ee98df9e636a51806e62ef9c4ab161) and evaluate suggested changes for code style compliance, pointing out any violations discovered. |
| 106 | +
|
| 107 | + 4. As a general guideline, try to provide any relevant, official, and supporting documentation links to any tool's suggestions in review comments. This guideline is important for posterity. |
| 108 | +
|
| 109 | + 5. As a project rule, Python source files with names prefixed by the string "test_" and located in the project's "tests" directory are the project's unit-testing code. It is safe, albeit a heuristic, to assume these are considered part of the project's minimal acceptance testing unless a justifying exception to this assumption is documented. |
| 110 | +
|
| 111 | + 6. As a project rule, any files without extensions and with names prefixed by either the string "check_" or the string "test_", and located in the project's "tests" directory, are the project's non-unit test code. "Non-unit test" in this context refers to any type of testing other than unit testing, such as (but not limited to) functional testing, style linting, regression testing, etc. It can also be assumed that non-unit testing code is usually written as Bash shell scripts. |
| 112 | + - path: requirements.txt |
| 113 | + instructions: >- |
| 114 | + * The project's own Python dependencies are recorded in 'requirements.txt' for production code. |
| 115 | +
|
| 116 | + * The project's testing-specific Python dependencies are recorded in 'tests/requirements.txt' and are used for testing the project. |
| 117 | +
|
| 118 | + * The project's documentation-specific Python dependencies are recorded in 'docs/requirements.txt' and are used only for generating Python-focused documentation for the project. 'docs/requirements.txt' may be absent if not applicable. |
| 119 | +
|
| 120 | + Consider these 'requirements.txt' files the records of truth regarding project dependencies. |
| 121 | + - path: tests/requirements.txt |
| 122 | + instructions: >- |
| 123 | + * The multicast project's own dependencies are recorded in |
| 124 | + './requirements.txt' for production code. |
| 125 | +
|
| 126 | + * The multicast project's own test code dependencies are recorded in |
| 127 | + 'tests/requirements.txt' for testing the project. |
| 128 | +
|
| 129 | + Consider these the records of truth regarding project test code dependencies. |
| 130 | + - path: .github/** |
| 131 | + instructions: >- |
| 132 | + * When the project is hosted on GitHub: All GitHub-specific configurations, templates, and tools should be found in the '.github' directory tree. |
| 133 | +
|
| 134 | + * 'actionlint' erroneously generates false positives when dealing with GitHub's `${{ ... }}` syntax in conditionals. |
| 135 | +
|
| 136 | + * 'actionlint' erroneously generates incorrect solutions when suggesting the removal of valid `${{ ... }}` syntax. |
| 137 | + - path: docs/* |
| 138 | + instructions: >- |
| 139 | + When a project contains a `docs/` directory: |
| 140 | +
|
| 141 | + 1. Consider the files in the `docs/` directory tree the core/main/in-depth documentation of the project. Also consider the 'docs/**.md' files the second place to look for project documentation after the 'README.md' file. |
| 142 | +
|
| 143 | + 2. When reviewing the documentation files (e.g. `docs/**.md`), they should additionally be linted with help from the tool `markdownlint`, pointing out any issues. |
| 144 | +
|
| 145 | + 3. When reviewing the documentation files in `docs/` directory, they should additionally be linted with help from the tool `languagetool`, pointing out any issues. |
| 146 | + abort_on_close: true |
| 147 | + auto_review: |
| 148 | + enabled: true |
| 149 | + auto_incremental_review: true |
| 150 | + ignore_title_keywords: [] |
| 151 | + labels: [] |
| 152 | + drafts: false |
| 153 | + base_branches: |
| 154 | + - stable |
| 155 | + - master |
| 156 | + - HOTFIX-* |
| 157 | + tools: |
| 158 | + languagetool: |
| 159 | + enabled: true |
| 160 | + language: en-US |
| 161 | + configuration: |
| 162 | + level: picky |
| 163 | + mother_tongue: en |
| 164 | + dictionary: |
| 165 | + - 'reactive-firewall' |
| 166 | + - 'CEP-9' |
| 167 | + - 'CEP-8' |
| 168 | + - 'CEP-7' |
| 169 | + - 'CEP-5' |
| 170 | + - 'Shellscript' |
| 171 | + - 'bash' |
| 172 | + disabled_rules: |
| 173 | + - EN_QUOTES |
| 174 | + - CONSECUTIVE_SPACES |
| 175 | + enabled_rules: |
| 176 | + - STYLE |
| 177 | + - EN_CONTRACTION_SPELLING |
| 178 | + - EN_WORD_COHERENCY |
| 179 | + - IT_IS_OBVIOUS |
| 180 | + - TWELFTH_OF_NEVER |
| 181 | + - OXFORD_SPELLING |
| 182 | + - PASSIVE_VOICE |
| 183 | + shellcheck: |
| 184 | + enabled: true |
| 185 | + ruff: |
| 186 | + enabled: true |
| 187 | + configuration: |
| 188 | + extend_select: |
| 189 | + - E # Pycodestyle errors (style issues) |
| 190 | + - F # PyFlakes codes (logical errors) |
| 191 | + - W # Pycodestyle warnings |
| 192 | + - N # PEP 8 naming conventions |
| 193 | + ignore: |
| 194 | + - W191 |
| 195 | + - W391 |
| 196 | + - E117 |
| 197 | + - D208 |
| 198 | + line_length: 100 |
| 199 | + dummy_variable_rgx: '^(_.*|junk|extra)$' # Variables starting with '_' or named 'junk' or 'extras', are considered dummy variables |
| 200 | + external: |
| 201 | + flake8-blind-except: {} |
| 202 | + flake8-docstrings: {} |
| 203 | + flake8-comprehensions: {} |
| 204 | + flake8-debugger: {} |
| 205 | + flake8-eradicate: {} |
| 206 | + # Include other Flake8 plugins as needed |
| 207 | + markdownlint: |
| 208 | + enabled: true |
| 209 | + yamllint: |
| 210 | + enabled: true |
| 211 | + configuration_file: ".yamllint.conf" |
| 212 | +chat: |
| 213 | + auto_reply: true |
0 commit comments