.coderabbit.yaml

# .coderabbit.yaml
---
language: en
early_access: true
reviews:
  enabled: true
  profile: assertive
  instructions: >-
    # Code Review Instructions

    - Ensure the code follows best practices and coding standards.
    - Check for security vulnerabilities and potential issues.
    - Ensure the code follows the **DRY, AHA, and SOLID** principles.
    - Our "Code Review Checklist Guide" is documented in
      [CEP-4](https://gist.github.com/reactive-firewall/cc041f10aad1d43a5ef15f50a6bbd5a5),
      be sure to always consider
      [CEP-4](https://gist.github.com/reactive-firewall/cc041f10aad1d43a5ef15f50a6bbd5a5) as
      implied instructional guidance.
    - For **Python** code, follow
      [PEP 20](https://www.python.org/dev/peps/pep-0020/),
      [PEP 483](https://peps.python.org/pep-0483/),
      [PEP 729](https://peps.python.org/pep-0729/), and
      [CEP-8](https://gist.github.com/reactive-firewall/b7ee98df9e636a51806e62ef9c4ab161)
      standards.
    - For **BASH** and **Shellscript** code, follow
      [Pure BASH Bible](https://github.com/dylanaraps/pure-bash-bible) standards.
    - Consider [CEP-5](https://gist.github.com/reactive-firewall/3d2bd3cf37f87974df6f7bee31a05a89)
      custom locking conventions.
    - Verify all **BASH** files (e.g. are of MIME-type 'text/x-shellscript') start with an
      [extensive disclaimer](https://gist.github.com/reactive-firewall/866b42d175ae3ebefcb2a5878b30ea17).

    # Documentation Review Instructions
    - Verify that documentation and comments are clear and comprehensive.
    - Verify that documentation and comments are free of spelling mistakes.
    - Verify that technical documentation includes a "References" section at
      the end of documentation, using the same format as actual RFCs, with
      both "Normative References" and "Informative References". Suggest improvements if unable.
    - Ensure that that project documentation and comments follow
      [CEP-7](https://gist.github.com/reactive-firewall/123b8a45f1bdeb064079e0524a29ec20)

    # Test Code Review Instructions
    - Ensure that test code is automated, comprehensive, and follows testing best practices.
    - Verify that all critical functionality is covered by tests.
    - Verify that minimal acceptance tests (e.g. those run by the workflow CI-MATs) are passing and
      error free, pointing out any failure as below minimal acceptance (i.e. un-acceptable).
    - Ensure that the test coverage meets or exceeds the project's required threshold
      (e.g., aiming for 100% coverage as per Issue #53).
    - For **test** code, *also* follow
      [CEP-9](https://gist.github.com/reactive-firewall/d840ee9990e65f302ce2a8d78ebe73f6)

    # Misc.
    - Verify that this file `.coderabbit.yaml` is present, validated, and current.
    - Confirm that the code meets the project's requirements and objectives.
    - Confirm that copyright years are up-to date whenever a file is changed.
    - Verify that dependencies are licensed under either the PSF License, a MIT License,
      a BSD License, the Unlicence, the Apache v2 License, or that the dependency is optional. Do
      not assume a dependency is optional, confirm if it is or is not optional.
    - For **Python** code, consider [PEP 290](https://peps.python.org/pep-0290/) whenever a python
      (e.g. has the extension '.py') file is changed.
  request_changes_workflow: true
  high_level_summary: true
  high_level_summary_placeholder: '@coderabbitai summary'
  auto_title_placeholder: '@coderabbitai'
  review_status: true
  poem: true
  collapse_walkthrough: false
  sequence_diagrams: true
  changed_files_summary: true
  labeling_instructions:
    - label: Python Lang
      instructions: Apply when the PR/MR contains changes to python source-code.
    - label: Bash Lang
      instructions: >-
        Apply when the PR/MR contains changes to shell-scripts or BASH code
        snippets.
    - label: Make Lang
      instructions: >-
        Apply when the PR/MR contains changes to the file `Makefile` or makefile
        code snippets.
    - label: Documentation
      instructions: >-
        Apply whenever project documentation (namely markdown source-code) is
        updated by the PR/MR. Also apply when PR contains a commit with a commit
        message prefixed with "[DOCUMENTATION] "
    - label: Linter
      instructions: >-
        Apply when the purpose of the PR/MR is related to fixing the feedback
        from a linter. Also apply if suggested fixes are used and improve the
        code's compliance with the PEP-8 standard.
  path_filters: ['!*.xc*/**', '!node_modules/**', '!dist/**', '!build/**', '!.git/**', '!venv/**', '!__pycache__/**']
  path_instructions:
    - path: README.md
      instructions: >-
        1. Consider the file 'README.md' the overview/introduction of the project.
           Also consider the 'README.md' file the first place to look for project documentation.
        2. When reviewing the file 'README.md' it should be linted with help
           from the tools `markdownlint` and `languagetool`, pointing out any issues.
        3. You may assume the file 'README.md' will contain GitHub flavor Markdown.
        4. The file `README.md` contains many links to additional valuable project documentation.
        5. Ensure the README is kept current.
    - path: '**/*.py'
      instructions: >-
        When reviewing **Python** code for this project:
        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.
        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.
        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.
        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.
        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. All documentation including docstrings in the project are to align with
           the guidelines set by
           [CEP-7](https://gist.github.com/reactive-firewall/123b8a45f1bdeb064079e0524a29ec20).
        6. Verify Flake8's configuration file is located at ".flake8.ini". Flake8 is run
           automaticly by the `flake8-cq` GHA used by the `.github/workflows/flake8.yml` workflow.
        7. Verify alignment of any new changes, with the code style advocated in
           [CEP-8](https://gist.github.com/reactive-firewall/b7ee98df9e636a51806e62ef9c4ab161),
           pointing out any introduced deviations.
    - path: 'tests/*'
      instructions: >-
        When reviewing **test** code:
        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.
        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.
        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.
        4. As a style convention, consider the code style advocated in
           [CEP-9](https://gist.github.com/reactive-firewall/d840ee9990e65f302ce2a8d78ebe73f6)
           and evaluate suggested changes for nomenclature compliance, pointing out any
           violations discovered, along with suggestions generated to correct the nomenclature.
        5. 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.
        6. 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.
        7. 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 (but not always) written as Bash shell scripts.
    - path: requirements.txt
      instructions: >-
        1. The project's own Python dependencies are recorded in 'requirements.txt' for
           production code.
        2. The project's testing-specific Python dependencies are recorded in
           'tests/requirements.txt' and are used for testing the project.
        3. 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.
        4. Consider these 'requirements.txt' files the records of truth regarding project
           dependencies.
        5. Consider the 'requirements.txt' file in the base of the git repository
           (e.g. './requirements.txt') the required python dependencies regarding Multicast project
           dependencies.
    - path: tests/requirements.txt
      instructions: >-
        1. The multicast project's own dependencies are recorded in './requirements.txt'
        for production code.
        2. The project's testing-specific Python dependencies are recorded in
           'tests/requirements.txt' and are used for testing the project.
        3. Consider these the records of truth regarding project test code dependencies.
        4. The project's testing-specific dependencies are **optional** and considered non-default
           extras when selected.
    - path: '.github/**'
      instructions: >-
        * When the project is hosted on GitHub: All GitHub-specific configurations, templates,
          and tools should be found in the '.github' directory tree.
        * 'actionlint' erroneously generates false positives when dealing with
          GitHub's `${{ ... }}` syntax in conditionals.
        * 'actionlint' erroneously generates incorrect solutions when suggesting the removal of
          valid `${{ ... }}` syntax.
    - path: 'docs/*'
      instructions: >-
        When a project contains a `docs/` directory:
        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.
        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.
        3. When reviewing the documentation files in `docs/` directory, they should additionally
           be linted with help from the tool `languagetool`, pointing out any issues.
  abort_on_close: true
  auto_review:
    enabled: true
    auto_incremental_review: true
    ignore_title_keywords: []
    labels: []
    drafts: false
    base_branches:
      - stable
      - master
      - HOTFIX-*
  tools:
    languagetool:
      enabled: true
      language: en-US
      configuration:
        level: picky
        mother_tongue: en
        dictionary:
          - 'reactive-firewall'
          - 'CEP-9'
          - 'CEP-8'
          - 'CEP-7'
          - 'CEP-5'
          - 'CEP-4'
          - 'Shellscript'
          - 'bash'
        disabled_rules:
          - EN_QUOTES
          - CONSECUTIVE_SPACES
        enabled_rules:
          - STYLE
          - EN_CONTRACTION_SPELLING
          - EN_WORD_COHERENCY
          - IT_IS_OBVIOUS
          - TWELFTH_OF_NEVER
          - OXFORD_SPELLING
          - PASSIVE_VOICE
    shellcheck:
      enabled: true
    ruff:
      enabled: true
      configuration:
        extend_select:
          - D  # Check documentation too
          - E  # Pycodestyle errors (style issues)
          - F  # PyFlakes codes (logical errors)
          - N  # PEP 8 naming conventions
          - W  # Pycodestyle warnings
        ignore:
          - W191
          - W391
          - E117
          - D208
        line_length: 100
        dummy_variable_rgx: '^(_.*|junk|extra)$'  # Variables starting with '_' or named 'junk' or 'extras', are considered dummy variables
        external:
          flake8-blind-except: {}
          flake8-docstrings: {}
          flake8-comprehensions: {}
          flake8-debugger: {}
          flake8-eradicate: {}
          # Include other Flake8 plugins as needed
    markdownlint:
      enabled: true
    yamllint:
      enabled: true
      configuration_file: ".yamllint.conf"
chat:
  auto_reply: true