[CI] Update for @coderabbitai instructions in .coderabbit.yml

reactive-firewall · reactive-firewall · commit 5b9e02cb0e09 · 2024-12-31T16:45:38.000-08:00
Changes in file .coderabbit.yaml:
 - updated config a bit
diff --git a/.coderabbit.yaml b/.coderabbit.yaml
@@ -2,51 +2,59 @@
 ---
 language: en
 early_access: true
-enable_free_tier: true
 reviews:
   enabled: true
-  profile: chill
+  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)
+      [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) and
-      [CEP-5](https://gist.github.com/reactive-firewall/3d2bd3cf37f87974df6f7bee31a05a89)
-      standards.
-    - Check all **BASH** files start with an
+      [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".
-    - Ensure that that documentation and comments follow
+      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
@@ -85,75 +93,109 @@ reviews:
       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.
-
-        6. Verify Flake8's configuration file is located at ".flake8.ini"
+        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 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 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.
-
-        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.
+        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: >-
-        * The project's own Python dependencies are recorded in 'requirements.txt' for production code.
-
-        * The project's testing-specific Python dependencies are recorded in 'tests/requirements.txt' and are used for testing the project.
-
-        * 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.
-
-        Consider these 'requirements.txt' files the records of truth regarding project dependencies.
+        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: >-
-        * The multicast project's own dependencies are recorded in
-        './requirements.txt' for production code.
-
-        * The multicast project's own test code dependencies are recorded in
-        'tests/requirements.txt' for testing the project.
-
-        Consider these the records of truth regarding project test code dependencies.
+        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.
+        * 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.
+        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
