ci: Add config file for CodeRabbit with custom rules#36
Merged
Conversation
Sourcery that we currently use cannot read documentation files and best practices, it's rather a refactoring tool. So I want to introduce CodeRabbit that allows creating .coderabbit.yaml with custom rules and conventions. Signed-off-by: Sergei Petrosian <spetrosi@redhat.com>
Reviewer's GuideAdds a new CodeRabbit configuration file (.coderabbit.yaml) that defines review behavior, disables non-essential features, enforces PR title/description conventions, and encodes detailed, path-specific review rules aligned with linux-system-roles best practices (especially for Ansible tasks, tests, templates, variables, and Python code). File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 1 issue, and left some high level feedback:
- The
path_instructionsglobtasks/**/*.ymlwill not matchtasks/main.ymlin many glob implementations; consider adding an explicittasks/*.ymlpattern if you want the core tasks files covered by these rules. - Several instructions are hardcoded to the
trustee_client_naming (variables, role name, examples); if this config is intended to be shared across multiple linux-system-roles, consider parameterizing or generalizing these references to avoid misleading guidance in other roles. - The review instructions mention enforcing test coverage and documentation updates for new variables and tasks, while the CodeRabbit
finishing_touches.unit_testsfeature is disabled; consider aligning these to avoid conflicting expectations for contributors and reviewers.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- The `path_instructions` glob `tasks/**/*.yml` will not match `tasks/main.yml` in many glob implementations; consider adding an explicit `tasks/*.yml` pattern if you want the core tasks files covered by these rules.
- Several instructions are hardcoded to the `trustee_client_` naming (variables, role name, examples); if this config is intended to be shared across multiple linux-system-roles, consider parameterizing or generalizing these references to avoid misleading guidance in other roles.
- The review instructions mention enforcing test coverage and documentation updates for new variables and tasks, while the CodeRabbit `finishing_touches.unit_tests` feature is disabled; consider aligning these to avoid conflicting expectations for contributors and reviewers.
## Individual Comments
### Comment 1
<location path=".coderabbit.yaml" line_range="203-204" />
<code_context>
+ # ========================================
+ # Variable Definitions - defaults/
+ # ========================================
+ - path: "defaults/**/*.yml"
+ instructions: |
+ - All variables MUST be prefixed with `trustee_client_`
+ - All variables MUST be stored in the file defaults/main.yml, Ansible
+ doesn't include variables from other files.
+ - These are user-facing API variables
</code_context>
<issue_to_address>
**suggestion:** Qualify the note about Ansible loading variables from defaults files to avoid confusion
The statement about Ansible "not including variables from other files" is only true in the context of `defaults/` (where only `defaults/main.yml` is auto-loaded). To avoid confusion with mechanisms like `vars_files` and `include_vars`, please reword to something like: "Ansible only auto-loads variables from defaults/main.yml" so the scope is explicit.
```suggestion
- All variables MUST be stored in the file defaults/main.yml. Ansible
only auto-loads variables from defaults/main.yml under defaults/.
```
</issue_to_address>Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
Comment on lines
+203
to
+204
| - All variables MUST be stored in the file defaults/main.yml, Ansible | ||
| doesn't include variables from other files. |
There was a problem hiding this comment.
suggestion: Qualify the note about Ansible loading variables from defaults files to avoid confusion
The statement about Ansible "not including variables from other files" is only true in the context of defaults/ (where only defaults/main.yml is auto-loaded). To avoid confusion with mechanisms like vars_files and include_vars, please reword to something like: "Ansible only auto-loads variables from defaults/main.yml" so the scope is explicit.
Suggested change
| - All variables MUST be stored in the file defaults/main.yml, Ansible | |
| doesn't include variables from other files. | |
| - All variables MUST be stored in the file defaults/main.yml. Ansible | |
| only auto-loads variables from defaults/main.yml under defaults/. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Sourcery that we currently use cannot read documentation files and best
practices, it's rather a refactoring tool.
So I want to introduce CodeRabbit that allows creating .coderabbit.yaml with
custom rules and conventions.
Signed-off-by: Sergei Petrosian spetrosi@redhat.com
Summary by Sourcery
CI: