mirror of
https://github.com/qodo-ai/pr-agent.git
synced 2025-07-08 14:50:40 +08:00
Improve markdown docs formatting for consistency and readability
This commit is contained in:
Peter Dave Hello
@ -1,9 +1,11 @@
|
||||
## Overview
|
||||
|
||||
The `analyze` tool combines advanced static code analysis with LLM capabilities to provide a comprehensive analysis of the PR code changes.
|
||||
|
||||
The tool scans the PR code changes, finds the code components (methods, functions, classes) that changed, and enables to interactively generate tests, docs, code suggestions and similar code search for each component.
|
||||
|
||||
It can be invoked manually by commenting on any PR:
|
||||
|
||||
```
|
||||
/analyze
|
||||
```
|
||||
|
||||
@ -2,6 +2,7 @@
|
||||
|
||||
The `ask` tool answers questions about the PR, based on the PR code changes. Make sure to be specific and clear in your questions.
|
||||
It can be invoked manually by commenting on any PR:
|
||||
|
||||
```
|
||||
/ask "..."
|
||||
```
|
||||
@ -15,6 +16,7 @@ It can be invoked manually by commenting on any PR:
|
||||
## Ask lines
|
||||
|
||||
You can run `/ask` on specific lines of code in the PR from the PR's diff view. The tool will answer questions based on the code changes in the selected lines.
|
||||
|
||||
- Click on the '+' sign next to the line number to select the line.
|
||||
- To select multiple lines, click on the '+' sign of the first line and then hold and drag to select the rest of the lines.
|
||||
- write `/ask "..."` in the comment box and press `Add single comment` button.
|
||||
@ -28,11 +30,13 @@ Note that the tool does not have "memory" of previous questions, and answers eac
|
||||
You can also ask questions about images that appear in the comment, where the entire PR code will be used as context.
|
||||
<br>
|
||||
The basic syntax is:
|
||||
|
||||
```
|
||||
/ask "..."
|
||||
|
||||
[Image](https://real_link_to_image)
|
||||
```
|
||||
|
||||
where `https://real_link_to_image` is the direct link to the image.
|
||||
|
||||
Note that GitHub has a built-in mechanism of pasting images in comments. However, pasted image does not provide a direct link.
|
||||
@ -55,5 +59,4 @@ To get a direct link to an image, we recommend using the following scheme:
|
||||
|
||||
{width=512}
|
||||
|
||||
|
||||
See a full video tutorial [here](https://codium.ai/images/pr_agent/ask_image_video.mov)
|
||||
|
||||
@ -18,20 +18,24 @@ The tool analyzes the failed checks and provides several feedbacks:
|
||||
___
|
||||
|
||||
In addition to being automatically triggered, the tool can also be invoked manually by commenting on a PR:
|
||||
|
||||
```
|
||||
/checks "https://github.com/{repo_name}/actions/runs/{run_number}/job/{job_number}"
|
||||
```
|
||||
|
||||
where `{repo_name}` is the name of the repository, `{run_number}` is the run number of the failed check, and `{job_number}` is the job number of the failed check.
|
||||
|
||||
## Disabling the tool from running automatically
|
||||
|
||||
If you wish to disable the tool from running automatically, you can do so by adding the following configuration to the configuration file:
|
||||
|
||||
```
|
||||
[checks]
|
||||
enable_auto_checks_feedback = false
|
||||
```
|
||||
|
||||
## Configuration options
|
||||
|
||||
- `enable_auto_checks_feedback` - if set to true, the tool will automatically provide feedback when a check is failed. Default is true.
|
||||
- `excluded_checks_list` - a list of checks to exclude from the feedback, for example: ["check1", "check2"]. Default is an empty list.
|
||||
- `persistent_comment` - if set to true, the tool will overwrite a previous checks comment with the new feedback. Default is true.
|
||||
|
||||
@ -1,7 +1,9 @@
|
||||
## Overview
|
||||
|
||||
The `generate_labels` tool scans the PR code changes, and given a list of labels and their descriptions, it automatically suggests labels that match the PR code changes.
|
||||
|
||||
It can be invoked manually by commenting on any PR:
|
||||
|
||||
```
|
||||
/generate_labels
|
||||
```
|
||||
@ -19,21 +21,26 @@ When running the `generate_labels` tool on a PR that includes changes in SQL que
|
||||
Note that in addition to the dedicated tool `generate_labels`, the custom labels will also be used by the `describe` tool.
|
||||
|
||||
### How to enable custom labels
|
||||
|
||||
There are 3 ways to enable custom labels:
|
||||
|
||||
#### 1. CLI (local configuration file)
|
||||
|
||||
When working from CLI, you need to apply the [configuration changes](#configuration-options) to the [custom_labels file](https://github.com/Codium-ai/pr-agent/blob/main/pr_agent/settings/custom_labels.toml):
|
||||
|
||||
#### 2. Repo configuration file
|
||||
|
||||
To enable custom labels, you need to apply the [configuration changes](#configuration-options) to the local `.pr_agent.toml` file in your repository.
|
||||
|
||||
#### 3. Handle custom labels from the Repo's labels page 💎
|
||||
|
||||
> This feature is available only in Qodo Merge
|
||||
|
||||
* GitHub : `https://github.com/{owner}/{repo}/labels`, or click on the "Labels" tab in the issues or PRs page.
|
||||
* GitLab : `https://gitlab.com/{owner}/{repo}/-/labels`, or click on "Manage" -> "Labels" on the left menu.
|
||||
|
||||
b. Add/edit the custom labels. It should be formatted as follows:
|
||||
|
||||
* Label name: The name of the custom label.
|
||||
* Description: Start the description of with prefix `pr_agent:`, for example: `pr_agent: Description of when AI should suggest this label`.<br>
|
||||
The description should be comprehensive and detailed, indicating when to add the desired label.
|
||||
@ -45,8 +52,9 @@ c. Now the custom labels will be included in the `generate_labels` tool.
|
||||
> This feature is supported in GitHub and GitLab.
|
||||
|
||||
## Configuration options
|
||||
- Change `enable_custom_labels` to True: This will turn off the default labels and enable the custom labels provided in the custom_labels.toml file.
|
||||
- Add the custom labels. It should be formatted as follows:
|
||||
|
||||
* Change `enable_custom_labels` to True: This will turn off the default labels and enable the custom labels provided in the custom_labels.toml file.
|
||||
* Add the custom labels. It should be formatted as follows:
|
||||
|
||||
```
|
||||
[config]
|
||||
|
||||
@ -1,4 +1,5 @@
|
||||
## Overview
|
||||
|
||||
The `custom_prompt` tool scans the PR code changes, and automatically generates suggestions for improving the PR code.
|
||||
It shares similarities with the `improve` tool, but with one main difference: the `custom_prompt` tool will **only propose suggestions that follow specific guidelines defined by the prompt** in: `pr_custom_prompt.prompt` configuration.
|
||||
|
||||
@ -17,7 +18,7 @@ The code suggestions should focus only on the following:
|
||||
|
||||
With a [configuration file](../usage-guide/automations_and_usage.md#github-app), use the following template:
|
||||
|
||||
```
|
||||
```toml
|
||||
[pr_custom_prompt]
|
||||
prompt="""\
|
||||
The suggestions should focus only on the following:
|
||||
@ -33,7 +34,8 @@ You might benefit from several trial-and-error iterations, until you get the cor
|
||||
## Example usage
|
||||
|
||||
Here is an example of a possible prompt, defined in the configuration file:
|
||||
```
|
||||
|
||||
```toml
|
||||
[pr_custom_prompt]
|
||||
prompt="""\
|
||||
The code suggestions should focus only on the following:
|
||||
|
||||
@ -1,7 +1,9 @@
|
||||
## Overview
|
||||
|
||||
The `describe` tool scans the PR code changes, and generates a description for the PR - title, type, summary, walkthrough and labels.
|
||||
|
||||
The tool can be triggered automatically every time a new PR is [opened](../usage-guide/automations_and_usage.md#github-app-automatic-tools-when-a-new-pr-is-opened), or it can be invoked manually by commenting on any PR:
|
||||
|
||||
```
|
||||
/describe
|
||||
```
|
||||
@ -19,6 +21,7 @@ After ~30 seconds, the tool will generate a description for the PR:
|
||||
{width=512}
|
||||
|
||||
If you want to edit [configurations](#configuration-options), add the relevant ones to the command:
|
||||
|
||||
```
|
||||
/describe --pr_description.some_config1=... --pr_description.some_config2=...
|
||||
```
|
||||
@ -26,6 +29,7 @@ If you want to edit [configurations](#configuration-options), add the relevant o
|
||||
### Automatic triggering
|
||||
|
||||
To run the `describe` automatically when a PR is opened, define in a [configuration file](https://qodo-merge-docs.qodo.ai/usage-guide/configuration_options/#wiki-configuration-file):
|
||||
|
||||
```
|
||||
[github_app]
|
||||
pr_commands = [
|
||||
@ -41,7 +45,6 @@ publish_labels = true
|
||||
- The `pr_commands` lists commands that will be executed automatically when a PR is opened.
|
||||
- The `[pr_description]` section contains the configurations for the `describe` tool you want to edit (if any).
|
||||
|
||||
|
||||
## Configuration options
|
||||
|
||||
!!! example "Possible configurations"
|
||||
@ -97,7 +100,6 @@ publish_labels = true
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
## Inline file summary 💎
|
||||
|
||||
This feature enables you to copy the `changes walkthrough` table to the "Files changed" tab, so you can quickly understand the changes in each file while reviewing the code changes (diff view).
|
||||
@ -120,13 +122,13 @@ If you prefer to have the file summaries appear in the "Files changed" tab on ev
|
||||
|
||||
**Note**: that this feature is currently available only for GitHub.
|
||||
|
||||
|
||||
## Markers template
|
||||
|
||||
To enable markers, set `pr_description.use_description_markers=true`.
|
||||
Markers enable to easily integrate user's content and auto-generated content, with a template-like mechanism.
|
||||
|
||||
For example, if the PR original description was:
|
||||
|
||||
```
|
||||
User content...
|
||||
|
||||
@ -139,6 +141,7 @@ pr_agent:summary
|
||||
## PR Walkthrough:
|
||||
pr_agent:walkthrough
|
||||
```
|
||||
|
||||
The marker `pr_agent:type` will be replaced with the PR type, `pr_agent:summary` will be replaced with the PR summary, and `pr_agent:walkthrough` will be replaced with the PR walkthrough.
|
||||
|
||||
{width=512}
|
||||
@ -147,13 +150,13 @@ becomes
|
||||
|
||||
{width=512}
|
||||
|
||||
|
||||
**Configuration params**:
|
||||
|
||||
- `use_description_markers`: if set to true, the tool will use markers template. It replaces every marker of the form `pr_agent:marker_name` with the relevant content. Default is false.
|
||||
- `include_generated_by_header`: if set to true, the tool will add a dedicated header: 'Generated by PR Agent at ...' to any automatic content. Default is true.
|
||||
|
||||
## Custom labels
|
||||
|
||||
The default labels of the describe tool are quite generic, since they are meant to be used in any repo: [`Bug fix`, `Tests`, `Enhancement`, `Documentation`, `Other`].
|
||||
|
||||
You can define custom labels that are relevant for your repo and use cases.
|
||||
@ -163,7 +166,9 @@ Make sure to provide proper title, and a detailed and well-phrased description f
|
||||
Each label description should be a **conditional statement**, that indicates if to add the label to the PR or not, according to the PR content.
|
||||
|
||||
### Handle custom labels from a configuration file
|
||||
|
||||
Example for a custom labels configuration setup in a configuration file:
|
||||
|
||||
```
|
||||
[config]
|
||||
enable_custom_labels=true
|
||||
@ -182,26 +187,25 @@ description = "use when a PR primarily contains new tests"
|
||||
|
||||
You can also control the custom labels that will be suggested by the `describe` tool from the repo's labels page:
|
||||
|
||||
* GitHub : go to `https://github.com/{owner}/{repo}/labels` (or click on the "Labels" tab in the issues or PRs page)
|
||||
* GitLab : go to `https://gitlab.com/{owner}/{repo}/-/labels` (or click on "Manage" -> "Labels" on the left menu)
|
||||
- GitHub : go to `https://github.com/{owner}/{repo}/labels` (or click on the "Labels" tab in the issues or PRs page)
|
||||
- GitLab : go to `https://gitlab.com/{owner}/{repo}/-/labels` (or click on "Manage" -> "Labels" on the left menu)
|
||||
|
||||
Now add/edit the custom labels. they should be formatted as follows:
|
||||
|
||||
* Label name: The name of the custom label.
|
||||
* Description: Start the description of with prefix `pr_agent:`, for example: `pr_agent: Description of when AI should suggest this label`.<br>
|
||||
- Label name: The name of the custom label.
|
||||
- Description: Start the description of with prefix `pr_agent:`, for example: `pr_agent: Description of when AI should suggest this label`.<br>
|
||||
|
||||
Examples for custom labels:
|
||||
|
||||
- `Main topic:performance` - pr_agent:The main topic of this PR is performance
|
||||
- `New endpoint` - pr_agent:A new endpoint was added in this PR
|
||||
- `SQL query` - pr_agent:A new SQL query was added in this PR
|
||||
- `Dockerfile changes` - pr_agent:The PR contains changes in the Dockerfile
|
||||
- ...
|
||||
- `Main topic:performance` - pr_agent:The main topic of this PR is performance
|
||||
- `New endpoint` - pr_agent:A new endpoint was added in this PR
|
||||
- `SQL query` - pr_agent:A new SQL query was added in this PR
|
||||
- `Dockerfile changes` - pr_agent:The PR contains changes in the Dockerfile
|
||||
- ...
|
||||
|
||||
The description should be comprehensive and detailed, indicating when to add the desired label. For example:
|
||||
{width=768}
|
||||
|
||||
|
||||
## Usage Tips
|
||||
|
||||
!!! tip "Automation"
|
||||
@ -211,14 +215,15 @@ The description should be comprehensive and detailed, indicating when to add the
|
||||
```
|
||||
meaning the `describe` tool will run automatically on every PR, with the default configurations.
|
||||
|
||||
- Markers are an alternative way to control the generated description, to give maximal control to the user. If you set:
|
||||
|
||||
- Markers are an alternative way to control the generated description, to give maximal control to the user. If you set:
|
||||
```
|
||||
pr_commands = ["/describe --pr_description.use_description_markers=true", ...]
|
||||
```
|
||||
|
||||
the tool will replace every marker of the form `pr_agent:marker_name` in the PR description with the relevant content, where `marker_name` is one of the following:
|
||||
* `type`: the PR type.
|
||||
*`type`: the PR type.
|
||||
* `summary`: the PR summary.
|
||||
* `walkthrough`: the PR walkthrough.
|
||||
|
||||
- Note that when markers are enabled, if the original PR description does not contain any markers, the tool will not alter the description at all.
|
||||
- Note that when markers are enabled, if the original PR description does not contain any markers, the tool will not alter the description at all.
|
||||
|
||||
@ -1,7 +1,9 @@
|
||||
## Overview
|
||||
|
||||
The `add_docs` tool scans the PR code changes, and automatically suggests documentation for any code components that changed in the PR (functions, classes, etc.).
|
||||
|
||||
It can be invoked manually by commenting on any PR:
|
||||
|
||||
```
|
||||
/add_docs
|
||||
```
|
||||
@ -19,13 +21,15 @@ The tool will generate documentation for all the components that changed in the
|
||||
{width=768}
|
||||
|
||||
You can state a name of a specific component in the PR to get documentation only for that component:
|
||||
|
||||
```
|
||||
/add_docs component_name
|
||||
```
|
||||
|
||||
## Configuration options
|
||||
- `docs_style`: The exact style of the documentation (for python docstring). you can choose between: `google`, `numpy`, `sphinx`, `restructuredtext`, `plain`. Default is `sphinx`.
|
||||
- `extra_instructions`: Optional extra instructions to the tool. For example: "focus on the changes in the file X. Ignore change in ...".
|
||||
|
||||
- `docs_style`: The exact style of the documentation (for python docstring). you can choose between: `google`, `numpy`, `sphinx`, `restructuredtext`, `plain`. Default is `sphinx`.
|
||||
- `extra_instructions`: Optional extra instructions to the tool. For example: "focus on the changes in the file X. Ignore change in ...".
|
||||
|
||||
!!! note "Notes"
|
||||
- The following languages are currently supported: Python, Java, C++, JavaScript, TypeScript, C#.
|
||||
|
||||
@ -1,13 +1,16 @@
|
||||
## Overview
|
||||
|
||||
The `help` tool provides a list of all the available tools and their descriptions.
|
||||
For Qodo Merge users, it also enables to trigger each tool by checking the relevant box.
|
||||
|
||||
It can be invoked manually by commenting on any PR:
|
||||
|
||||
```
|
||||
/help
|
||||
```
|
||||
|
||||
## Example usage
|
||||
|
||||
An example [result](https://github.com/Codium-ai/pr-agent/pull/546#issuecomment-1868524805):
|
||||
|
||||
{width=750}
|
||||
|
||||
@ -3,9 +3,11 @@
|
||||
The `help_docs` tool can answer a free-text question based on a git documentation folder.
|
||||
|
||||
It can be invoked manually by commenting on any PR or Issue:
|
||||
|
||||
```
|
||||
/help_docs "..."
|
||||
```
|
||||
|
||||
Or configured to be triggered automatically when a [new issue is opened](#run-as-a-github-action).
|
||||
|
||||
The tool assumes by default that the documentation is located in the root of the repository, at `/docs` folder.
|
||||
@ -92,8 +94,8 @@ jobs:
|
||||
|
||||
3) Following completion of the remaining steps (such as adding secrets and relevant configurations, such as `repo_url` and `docs_path`) merge this change to your main branch.
|
||||
When a new issue is opened, you should see a comment from `github-actions` bot with an auto response, assuming the question is related to the documentation of the repository.
|
||||
---
|
||||
|
||||
---
|
||||
|
||||
## Configuration options
|
||||
|
||||
|
||||
@ -7,28 +7,31 @@ It leverages LLM technology to transform PR comments and review suggestions into
|
||||
|
||||
## Usage Scenarios
|
||||
|
||||
|
||||
### For Reviewers
|
||||
|
||||
Reviewers can request code changes by:
|
||||
|
||||
1. Selecting the code block to be modified.
|
||||
2. Adding a comment with the syntax:
|
||||
2. Adding a comment with the syntax:
|
||||
|
||||
```
|
||||
/implement <code-change-description>
|
||||
```
|
||||
|
||||
{width=640}
|
||||
|
||||
|
||||
### For PR Authors
|
||||
|
||||
PR authors can implement suggested changes by replying to a review comment using either: <br>
|
||||
|
||||
1. Add specific implementation details as described above
|
||||
|
||||
```
|
||||
/implement <code-change-description>
|
||||
```
|
||||
|
||||
2. Use the original review comment as instructions
|
||||
|
||||
```
|
||||
/implement
|
||||
```
|
||||
@ -38,6 +41,7 @@ PR authors can implement suggested changes by replying to a review comment using
|
||||
### For Referencing Comments
|
||||
|
||||
You can reference and implement changes from any comment by:
|
||||
|
||||
```
|
||||
/implement <link-to-review-comment>
|
||||
```
|
||||
@ -46,7 +50,6 @@ You can reference and implement changes from any comment by:
|
||||
|
||||
Note that the implementation will occur within the review discussion thread.
|
||||
|
||||
|
||||
**Configuration options**
|
||||
|
||||
- Use `/implement` to implement code change within and based on the review discussion.
|
||||
|
||||
@ -1,6 +1,8 @@
|
||||
## Overview
|
||||
|
||||
The `improve` tool scans the PR code changes, and automatically generates [meaningful](https://github.com/Codium-ai/pr-agent/blob/main/pr_agent/settings/pr_code_suggestions_prompts.toml#L41) suggestions for improving the PR code.
|
||||
The tool can be triggered automatically every time a new PR is [opened](../usage-guide/automations_and_usage.md#github-app-automatic-tools-when-a-new-pr-is-opened), or it can be invoked manually by commenting on any PR:
|
||||
|
||||
```toml
|
||||
/improve
|
||||
```
|
||||
@ -20,24 +22,26 @@ The tool can be triggered automatically every time a new PR is [opened](../usage
|
||||
Invoke the tool manually by commenting `/improve` on any PR. The code suggestions by default are presented as a single comment:
|
||||
|
||||
To edit [configurations](#configuration-options) related to the improve tool, use the following template:
|
||||
|
||||
```toml
|
||||
/improve --pr_code_suggestions.some_config1=... --pr_code_suggestions.some_config2=...
|
||||
```
|
||||
|
||||
For example, you can choose to present all the suggestions as commitable code comments, by running the following command:
|
||||
|
||||
```toml
|
||||
/improve --pr_code_suggestions.commitable_code_suggestions=true
|
||||
```
|
||||
|
||||
{width=512}
|
||||
|
||||
|
||||
As can be seen, a single table comment has a significantly smaller PR footprint. We recommend this mode for most cases.
|
||||
Also note that collapsible are not supported in _Bitbucket_. Hence, the suggestions can only be presented in Bitbucket as code comments.
|
||||
|
||||
### Automatic triggering
|
||||
|
||||
To run the `improve` automatically when a PR is opened, define in a [configuration file](https://qodo-merge-docs.qodo.ai/usage-guide/configuration_options/#wiki-configuration-file):
|
||||
|
||||
```toml
|
||||
[github_app]
|
||||
pr_commands = [
|
||||
@ -54,6 +58,7 @@ num_code_suggestions_per_chunk = ...
|
||||
- The `[pr_code_suggestions]` section contains the configurations for the `improve` tool you want to edit (if any)
|
||||
|
||||
### Assessing Impact
|
||||
|
||||
>`💎 feature`
|
||||
|
||||
Qodo Merge tracks two types of implementations for tracking implemented suggestions:
|
||||
@ -70,6 +75,7 @@ In post-process, Qodo Merge counts the number of suggestions that were implement
|
||||
{width=512}
|
||||
|
||||
## Suggestion tracking
|
||||
|
||||
>`💎 feature. Platforms supported: GitHub, GitLab`
|
||||
|
||||
Qodo Merge employs a novel detection system to automatically [identify](https://qodo-merge-docs.qodo.ai/core-abilities/impact_evaluation/) AI code suggestions that PR authors have accepted and implemented.
|
||||
@ -107,6 +113,7 @@ You can use the `extra_instructions` configuration option to give the AI model a
|
||||
Be specific, clear, and concise in the instructions. With extra instructions, you are the prompter.
|
||||
|
||||
Examples for possible instructions:
|
||||
|
||||
```toml
|
||||
[pr_code_suggestions]
|
||||
extra_instructions="""\
|
||||
@ -116,6 +123,7 @@ extra_instructions="""\
|
||||
...
|
||||
"""
|
||||
```
|
||||
|
||||
Use triple quotes to write multi-line instructions. Use bullet points or numbers to make the instructions more readable.
|
||||
|
||||
### Best practices
|
||||
@ -129,6 +137,7 @@ The AI model will use this `best_practices.md` file as a reference, and in case
|
||||
best practice`.
|
||||
|
||||
Example for a python `best_practices.md` content:
|
||||
|
||||
```markdown
|
||||
## Project best practices
|
||||
- Make sure that I/O operations are encapsulated in a try-except block
|
||||
@ -145,10 +154,11 @@ Tips for writing an effective `best_practices.md` file:
|
||||
- Include brief code examples when helpful
|
||||
- Focus on project-specific guidelines, that will result in relevant suggestions you actually want to get
|
||||
- Keep the file relatively short, under 800 lines, since:
|
||||
- AI models may not process effectively very long documents
|
||||
- Long files tend to contain generic guidelines already known to AI
|
||||
- AI models may not process effectively very long documents
|
||||
- Long files tend to contain generic guidelines already known to AI
|
||||
|
||||
#### Local and global best practices
|
||||
|
||||
By default, Qodo Merge will look for a local `best_practices.md` in the root of the relevant local repo.
|
||||
|
||||
If you want to enable also a global `best_practices.md` file, set first in the global configuration file:
|
||||
@ -161,7 +171,8 @@ enable_global_best_practices = true
|
||||
Then, create a `best_practices.md` file in the root of [global](https://qodo-merge-docs.qodo.ai/usage-guide/configuration_options/#global-configuration-file) configuration repository, `pr-agent-settings`.
|
||||
|
||||
#### Best practices for multiple languages
|
||||
For a git organization working with multiple programming languages, you can maintain a centralized global `best_practices.md` file containing language-specific guidelines.
|
||||
|
||||
For a git organization working with multiple programming languages, you can maintain a centralized global `best_practices.md` file containing language-specific guidelines.
|
||||
When reviewing pull requests, Qodo Merge automatically identifies the programming language and applies the relevant best practices from this file.
|
||||
|
||||
To do this, structure your `best_practices.md` file using the following format:
|
||||
@ -176,7 +187,8 @@ To do this, structure your `best_practices.md` file using the following format:
|
||||
```
|
||||
|
||||
#### Dedicated label for best practices suggestions
|
||||
Best practice suggestions are labeled as `Organization best practice` by default.
|
||||
|
||||
Best practice suggestions are labeled as `Organization best practice` by default.
|
||||
To customize this label, modify it in your configuration file:
|
||||
|
||||
```toml
|
||||
@ -186,7 +198,6 @@ organization_name = "..."
|
||||
|
||||
And the label will be: `{organization_name} best practice`.
|
||||
|
||||
|
||||
#### Example results
|
||||
|
||||
{width=512}
|
||||
@ -201,7 +212,7 @@ And the label will be: `{organization_name} best practice`.
|
||||
2. **Automatically** generates [best practices page](https://github.com/qodo-ai/pr-agent/wiki/.pr_agent_auto_best_practices) based on what your team consistently values
|
||||
3. Applies these learned patterns to future code reviews
|
||||
|
||||
This creates an automatic feedback loop where the system continuously learns from your team's choices to provide increasingly relevant suggestions.
|
||||
This creates an automatic feedback loop where the system continuously learns from your team's choices to provide increasingly relevant suggestions.
|
||||
The system maintains two analysis phases:
|
||||
|
||||
- Open exploration for new issues
|
||||
@ -227,8 +238,8 @@ extra_instructions = ""
|
||||
max_patterns = 5
|
||||
```
|
||||
|
||||
|
||||
### Combining 'extra instructions' and 'best practices'
|
||||
|
||||
> `💎 feature`
|
||||
|
||||
The `extra instructions` configuration is more related to the `improve` tool prompt. It can be used, for example, to avoid specific suggestions ("Don't suggest to add try-except block", "Ignore changes in toml files", ...) or to emphasize specific aspects or formats ("Answer in Japanese", "Give only short suggestions", ...)
|
||||
@ -237,10 +248,10 @@ In contrast, the `best_practices.md` file is a general guideline for the way cod
|
||||
|
||||
Using a combination of both can help the AI model to provide relevant and tailored suggestions.
|
||||
|
||||
|
||||
## Usage Tips
|
||||
|
||||
### Implementing the proposed code suggestions
|
||||
|
||||
Each generated suggestion consists of three key elements:
|
||||
|
||||
1. A single-line summary of the proposed change
|
||||
@ -252,6 +263,7 @@ In addition to mistakes (which may happen, but are rare), sometimes the presente
|
||||
In such cases, we recommend prioritizing the suggestion's detailed description, using the diff snippet primarily as a supporting reference.
|
||||
|
||||
### Dual publishing mode
|
||||
|
||||
Our recommended approach for presenting code suggestions is through a [table](https://qodo-merge-docs.qodo.ai/tools/improve/#overview) (`--pr_code_suggestions.commitable_code_suggestions=false`).
|
||||
This method significantly reduces the PR footprint and allows for quick and easy digestion of multiple suggestions.
|
||||
|
||||
@ -268,9 +280,11 @@ dual_publishing_score_threshold = x
|
||||
Where x represents the minimum score threshold (>=) for suggestions to be presented as commitable PR comments in addition to the table. Default is -1 (disabled).
|
||||
|
||||
### Self-review
|
||||
|
||||
> `💎 feature` Platforms supported: GitHub, GitLab
|
||||
|
||||
If you set in a configuration file:
|
||||
|
||||
```toml
|
||||
[pr_code_suggestions]
|
||||
demand_code_suggestions_self_review = true
|
||||
@ -278,6 +292,7 @@ demand_code_suggestions_self_review = true
|
||||
|
||||
The `improve` tool will add a checkbox below the suggestions, prompting user to acknowledge that they have reviewed the suggestions.
|
||||
You can set the content of the checkbox text via:
|
||||
|
||||
```toml
|
||||
[pr_code_suggestions]
|
||||
code_suggestions_self_review_text = "... (your text here) ..."
|
||||
@ -285,7 +300,6 @@ code_suggestions_self_review_text = "... (your text here) ..."
|
||||
|
||||
{width=512}
|
||||
|
||||
|
||||
!!! tip "Tip - Reducing visual footprint after self-review 💎"
|
||||
|
||||
The configuration parameter `pr_code_suggestions.fold_suggestions_on_self_review` (default is True)
|
||||
@ -293,8 +307,6 @@ code_suggestions_self_review_text = "... (your text here) ..."
|
||||
|
||||
This reduces the visual footprint of the suggestions, and also indicates to the PR reviewer that the suggestions have been reviewed by the PR author, and don't require further attention.
|
||||
|
||||
|
||||
|
||||
!!! tip "Tip - Demanding self-review from the PR author 💎"
|
||||
|
||||
By setting:
|
||||
@ -314,12 +326,14 @@ code_suggestions_self_review_text = "... (your text here) ..."
|
||||
To prevent unauthorized approvals, this configuration defaults to false, and cannot be altered through online comments; enabling requires a direct update to the configuration file and a commit to the repository. This ensures that utilizing the feature demands a deliberate documented decision by the repository owner.
|
||||
|
||||
### Auto-approval
|
||||
|
||||
> `💎 feature. Platforms supported: GitHub, GitLab, Bitbucket`
|
||||
|
||||
Under specific conditions, Qodo Merge can auto-approve a PR when a specific comment is invoked, or when the PR meets certain criteria.
|
||||
|
||||
**To ensure safety, the auto-approval feature is disabled by default.**
|
||||
To enable auto-approval features, you need to actively set one or both of the following options in a pre-defined _configuration file_:
|
||||
|
||||
```toml
|
||||
[config]
|
||||
enable_comment_approval = true # For approval via comments
|
||||
@ -333,20 +347,24 @@ enable_auto_approval = true # For criteria-based auto-approval
|
||||
1\. **Auto-approval by commenting**
|
||||
|
||||
To enable auto-approval by commenting, set in the configuration file:
|
||||
|
||||
```toml
|
||||
[config]
|
||||
enable_comment_approval = true
|
||||
```
|
||||
|
||||
After enabling, by commenting on a PR:
|
||||
|
||||
```
|
||||
/review auto_approve
|
||||
```
|
||||
|
||||
Qodo Merge will automatically approve the PR, and add a comment with the approval.
|
||||
|
||||
2\. **Auto-approval when the PR meets certain criteria**
|
||||
|
||||
To enable auto-approval based on specific criteria, first, you need to enable the top-level flag:
|
||||
|
||||
```toml
|
||||
[config]
|
||||
enable_auto_approval = true
|
||||
@ -355,30 +373,38 @@ enable_auto_approval = true
|
||||
There are two criteria that can be set for auto-approval:
|
||||
|
||||
- **Review effort score**
|
||||
|
||||
```toml
|
||||
[config]
|
||||
enable_auto_approval = true
|
||||
auto_approve_for_low_review_effort = X # X is a number between 1 to 5
|
||||
```
|
||||
|
||||
When the [review effort score](https://www.qodo.ai/images/pr_agent/review3.png) is lower or equal to X, the PR will be auto-approved.
|
||||
|
||||
___
|
||||
|
||||
- **No code suggestions**
|
||||
|
||||
```toml
|
||||
[config]
|
||||
enable_auto_approval = true
|
||||
auto_approve_for_no_suggestions = true
|
||||
```
|
||||
|
||||
When no [code suggestion](https://www.qodo.ai/images/pr_agent/code_suggestions_as_comment_closed.png) were found for the PR, the PR will be auto-approved.
|
||||
|
||||
### How many code suggestions are generated?
|
||||
|
||||
Qodo Merge uses a dynamic strategy to generate code suggestions based on the size of the pull request (PR). Here's how it works:
|
||||
|
||||
#### 1. Chunking large PRs
|
||||
|
||||
- Qodo Merge divides large PRs into 'chunks'.
|
||||
- Each chunk contains up to `pr_code_suggestions.max_context_tokens` tokens (default: 14,000).
|
||||
|
||||
#### 2. Generating suggestions
|
||||
|
||||
- For each chunk, Qodo Merge generates up to `pr_code_suggestions.num_code_suggestions_per_chunk` suggestions (default: 3).
|
||||
|
||||
This approach has two main benefits:
|
||||
@ -388,7 +414,6 @@ This approach has two main benefits:
|
||||
|
||||
Note: Chunking is primarily relevant for large PRs. For most PRs (up to 500 lines of code), Qodo Merge will be able to process the entire code in a single call.
|
||||
|
||||
|
||||
## Configuration options
|
||||
|
||||
??? example "General options"
|
||||
@ -468,8 +493,8 @@ Note: Chunking is primarily relevant for large PRs. For most PRs (up to 500 line
|
||||
|
||||
- **AI Limitations:** AI models for code are getting better and better, but they are not flawless. Not all the suggestions will be perfect, and a user should not accept all of them automatically. Critical reading and judgment are required. Mistakes of the AI are rare but can happen, and it is usually quite easy for a human to spot them.
|
||||
- **Purpose of Suggestions:**
|
||||
- **Self-reflection:** The suggestions aim to enable developers to _self-reflect_ and improve their pull requests. This process can help to identify blind spots, uncover missed edge cases, and enhance code readability and coherency. Even when a specific code suggestion isn't suitable, the underlying issue it highlights often reveals something important that might deserve attention.
|
||||
- **Bug detection:** The suggestions also alert on any _critical bugs_ that may have been identified during the analysis. This provides an additional safety net to catch potential issues before they make it into production. It's perfectly acceptable to implement only the suggestions you find valuable for your specific context.
|
||||
- **Self-reflection:** The suggestions aim to enable developers to _self-reflect_ and improve their pull requests. This process can help to identify blind spots, uncover missed edge cases, and enhance code readability and coherency. Even when a specific code suggestion isn't suitable, the underlying issue it highlights often reveals something important that might deserve attention.
|
||||
- **Bug detection:** The suggestions also alert on any _critical bugs_ that may have been identified during the analysis. This provides an additional safety net to catch potential issues before they make it into production. It's perfectly acceptable to implement only the suggestions you find valuable for your specific context.
|
||||
- **Hierarchy:** Presenting the suggestions in a structured hierarchical table enables the user to _quickly_ understand them, and to decide which ones are relevant and which are not.
|
||||
- **Customization:** To guide the model to suggestions that are more relevant to the specific needs of your project, we recommend to use the [`extra_instructions`](https://qodo-merge-docs.qodo.ai/tools/improve/#extra-instructions-and-best-practices) and [`best practices`](https://qodo-merge-docs.qodo.ai/tools/improve/#best-practices) fields.
|
||||
- **Interactive usage:** The interactive [PR chat](https://qodo-merge-docs.qodo.ai/chrome-extension/) also provides an easy way to get more tailored suggestions and feedback from the AI model.
|
||||
|
||||
@ -1,13 +1,14 @@
|
||||
## Overview
|
||||
|
||||
The `improve_component` tool generates code suggestions for a specific code component that changed in the PR.
|
||||
it can be invoked manually by commenting on any PR:
|
||||
|
||||
```
|
||||
/improve_component component_name
|
||||
```
|
||||
|
||||
To get a list of the components that changed in the PR and choose the relevant component interactively, use the [`analyze`](./analyze.md) tool.
|
||||
|
||||
|
||||
## Example usage
|
||||
|
||||
Invoke the tool manually by commenting `/improve_component` on any PR:
|
||||
@ -23,6 +24,7 @@ The tool will generate code suggestions for the selected component (if no compon
|
||||
- This tool can also be triggered interactively by using the [`analyze`](./analyze.md) tool.
|
||||
|
||||
## Configuration options
|
||||
|
||||
- `num_code_suggestions`: number of code suggestions to provide. Default is 4
|
||||
- `extra_instructions`: Optional extra instructions to the tool. For example: "focus on ...".
|
||||
- `file`: in case there are several components with the same name, you can specify the relevant file.
|
||||
|
||||
@ -2,22 +2,23 @@
|
||||
|
||||
Here is a list of Qodo Merge tools, each with a dedicated page that explains how to use it:
|
||||
|
||||
| Tool | Description |
|
||||
|------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| **[PR Description (`/describe`](./describe.md))** | Automatically generating PR description - title, type, summary, code walkthrough and labels |
|
||||
| **[PR Review (`/review`](./review.md))** | Adjustable feedback about the PR, possible issues, security concerns, review effort and more |
|
||||
| **[Code Suggestions (`/improve`](./improve.md))** | Code suggestions for improving the PR |
|
||||
| **[Question Answering (`/ask ...`](./ask.md))** | Answering free-text questions about the PR, or on specific code lines |
|
||||
| **[Update Changelog (`/update_changelog`](./update_changelog.md))** | Automatically updating the CHANGELOG.md file with the PR changes |
|
||||
| **[Help (`/help`](./help.md))** | Provides a list of all the available tools. Also enables to trigger them interactively (💎) |
|
||||
| **💎 [Add Documentation (`/add_docs`](./documentation.md))** | Generates documentation to methods/functions/classes that changed in the PR |
|
||||
| **💎 [Generate Custom Labels (`/generate_labels`](./custom_labels.md))** | Generates custom labels for the PR, based on specific guidelines defined by the user |
|
||||
| **💎 [Analyze (`/analyze`](./analyze.md))** | Identify code components that changed in the PR, and enables to interactively generate tests, docs, and code suggestions for each component|
|
||||
| **💎 [Test (`/test`](./test.md))** | generate tests for a selected component, based on the PR code changes |
|
||||
| **💎 [Custom Prompt (`/custom_prompt`](./custom_prompt.md))** | Automatically generates custom suggestions for improving the PR code, based on specific guidelines defined by the user |
|
||||
| **💎 [Generate Tests (`/test component_name`](./test.md))** | Automatically generates unit tests for a selected component, based on the PR code changes |
|
||||
| **💎 [Improve Component (`/improve_component component_name`](./improve_component.md))** | Generates code suggestions for a specific code component that changed in the PR |
|
||||
| **💎 [CI Feedback (`/checks ci_job`](./ci_feedback.md))** | Automatically generates feedback and analysis for a failed CI job |
|
||||
| **💎 [Implement (`/implement`](./implement.md))** | Generates implementation code from review suggestions |
|
||||
| **💎 [Scan Repo Discussions (`/scan_repo_discussions`](./scan_repo_discussions.md))** | Generates `best_practices.md` file based on previous discussions in the repository |
|
||||
| Tool | Description |
|
||||
| ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **[PR Description (`/describe`](./describe.md))** | Automatically generating PR description - title, type, summary, code walkthrough and labels |
|
||||
| **[PR Review (`/review`](./review.md))** | Adjustable feedback about the PR, possible issues, security concerns, review effort and more |
|
||||
| **[Code Suggestions (`/improve`](./improve.md))** | Code suggestions for improving the PR |
|
||||
| **[Question Answering (`/ask ...`](./ask.md))** | Answering free-text questions about the PR, or on specific code lines |
|
||||
| **[Update Changelog (`/update_changelog`](./update_changelog.md))** | Automatically updating the CHANGELOG.md file with the PR changes |
|
||||
| **[Help (`/help`](./help.md))** | Provides a list of all the available tools. Also enables to trigger them interactively (💎) |
|
||||
| **💎 [Add Documentation (`/add_docs`](./documentation.md))** | Generates documentation to methods/functions/classes that changed in the PR |
|
||||
| **💎 [Generate Custom Labels (`/generate_labels`](./custom_labels.md))** | Generates custom labels for the PR, based on specific guidelines defined by the user |
|
||||
| **💎 [Analyze (`/analyze`](./analyze.md))** | Identify code components that changed in the PR, and enables to interactively generate tests, docs, and code suggestions for each component |
|
||||
| **💎 [Test (`/test`](./test.md))** | generate tests for a selected component, based on the PR code changes |
|
||||
| **💎 [Custom Prompt (`/custom_prompt`](./custom_prompt.md))** | Automatically generates custom suggestions for improving the PR code, based on specific guidelines defined by the user |
|
||||
| **💎 [Generate Tests (`/test component_name`](./test.md))** | Automatically generates unit tests for a selected component, based on the PR code changes |
|
||||
| **💎 [Improve Component (`/improve_component component_name`](./improve_component.md))** | Generates code suggestions for a specific code component that changed in the PR |
|
||||
| **💎 [CI Feedback (`/checks ci_job`](./ci_feedback.md))** | Automatically generates feedback and analysis for a failed CI job |
|
||||
| **💎 [Implement (`/implement`](./implement.md))** | Generates implementation code from review suggestions |
|
||||
| **💎 [Scan Repo Discussions (`/scan_repo_discussions`](./scan_repo_discussions.md))** | Generates `best_practices.md` file based on previous discussions in the repository |
|
||||
|
||||
Note that the tools marked with 💎 are available only for Qodo Merge users.
|
||||
|
||||
@ -1,7 +1,9 @@
|
||||
## Overview
|
||||
|
||||
The `review` tool scans the PR code changes, and generates a list of feedbacks about the PR, aiming to aid the reviewing process.
|
||||
<br>
|
||||
The tool can be triggered automatically every time a new PR is [opened](../usage-guide/automations_and_usage.md#github-app-automatic-tools-when-a-new-pr-is-opened), or can be invoked manually by commenting on any PR:
|
||||
|
||||
```
|
||||
/review
|
||||
```
|
||||
@ -10,7 +12,6 @@ Note that the main purpose of the `review` tool is to provide the **PR reviewer*
|
||||
|
||||
(Read more about the different personas in the PR process and how Qodo Merge aims to assist them in our [blog](https://www.codium.ai/blog/understanding-the-challenges-and-pain-points-of-the-pull-request-cycle/))
|
||||
|
||||
|
||||
## Example usage
|
||||
|
||||
### Manual triggering
|
||||
@ -24,6 +25,7 @@ After ~30 seconds, the tool will generate a review for the PR:
|
||||
{width=512}
|
||||
|
||||
If you want to edit [configurations](#configuration-options), add the relevant ones to the command:
|
||||
|
||||
```
|
||||
/review --pr_reviewer.some_config1=... --pr_reviewer.some_config2=...
|
||||
```
|
||||
@ -31,6 +33,7 @@ If you want to edit [configurations](#configuration-options), add the relevant o
|
||||
### Automatic triggering
|
||||
|
||||
To run the `review` automatically when a PR is opened, define in a [configuration file](https://qodo-merge-docs.qodo.ai/usage-guide/configuration_options/#wiki-configuration-file):
|
||||
|
||||
```
|
||||
[github_app]
|
||||
pr_commands = [
|
||||
@ -46,7 +49,6 @@ extra_instructions = "..."
|
||||
- The `pr_commands` lists commands that will be executed automatically when a PR is opened.
|
||||
- The `[pr_reviewer]` section contains the configurations for the `review` tool you want to edit (if any).
|
||||
|
||||
|
||||
## Configuration options
|
||||
|
||||
!!! example "General options"
|
||||
@ -114,7 +116,6 @@ extra_instructions = "..."
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
|
||||
## Usage Tips
|
||||
|
||||
!!! tip "General guidelines"
|
||||
@ -164,11 +165,6 @@ extra_instructions = "..."
|
||||
```
|
||||
Use triple quotes to write multi-line instructions. Use bullet points to make the instructions more readable.
|
||||
|
||||
|
||||
|
||||
|
||||
!!! tip "Code suggestions"
|
||||
|
||||
The `review` tool previously included a legacy feature for providing code suggestions (controlled by `--pr_reviewer.num_code_suggestion`). This functionality has been deprecated and replaced by the [`improve`](./improve.md) tool, which offers higher quality and more actionable code suggestions.
|
||||
|
||||
|
||||
|
||||
@ -5,7 +5,7 @@
|
||||
The `scan_repo_discussions` tool analyzes code discussions (meaning review comments over code lines) from merged pull requests over the past 12 months.
|
||||
It processes these discussions alongside other PR metadata to identify recurring patterns in team feedback and code reviews, generating a comprehensive [`best_practices.md`](https://github.com/qodo-ai/pr-agent/blob/qodo-merge-best-practices_2025-04-16_1018/best_practices.md) document that distills key insights and recommendations.
|
||||
|
||||
This file captures repository-specific patterns derived from your team's actual workflow and discussions, rather than more generic best practices.
|
||||
This file captures repository-specific patterns derived from your team's actual workflow and discussions, rather than more generic best practices.
|
||||
It will be utilized by Qodo Merge to provide tailored suggestions for improving code quality in future pull requests.
|
||||
|
||||
!!! note "Active repositories are needed"
|
||||
@ -16,9 +16,8 @@ It will be utilized by Qodo Merge to provide tailored suggestions for improving
|
||||
Teams are encouraged to further customize and refine these insights to better align with their specific development priorities and contexts.
|
||||
This can be done by editing the `best_practices.md` file directly when the PR is created, or iteratively over time to enhance the 'best practices' suggestions provided by Qodo Merge.
|
||||
|
||||
|
||||
|
||||
The tool can be invoked manually by commenting on any PR:
|
||||
|
||||
```
|
||||
/scan_repo_discussions
|
||||
```
|
||||
@ -28,7 +27,6 @@ Note that the scan can take several minutes to complete, since up to 250 PRs are
|
||||
|
||||
## Example usage
|
||||
|
||||
|
||||
{width=640}
|
||||
|
||||
The PR created by the bot:
|
||||
@ -43,4 +41,4 @@ The `best_practices.md` file in the PR:
|
||||
|
||||
- Use `/scan_repo_discussions --scan_repo_discussions.force_scan=true` to force generating a PR with a new `best_practices.md` file, even if it already exists (by default, the bot will not generate a new file if it already exists).
|
||||
- Use `/scan_repo_discussions --scan_repo_discussions.days_back=X` to specify the number of days back to scan for discussions. The default is 365 days.
|
||||
- Use `/scan_repo_discussions --scan_repo_discussions.minimal_number_of_prs=X` to specify the minimum number of merged PRs needed to generate the `best_practices.md` file. The default is 50 PRs.
|
||||
- Use `/scan_repo_discussions --scan_repo_discussions.minimal_number_of_prs=X` to specify the minimum number of merged PRs needed to generate the `best_practices.md` file. The default is 50 PRs.
|
||||
|
||||
@ -1,4 +1,5 @@
|
||||
## Overview
|
||||
|
||||
The similar code tool retrieves the most similar code components from inside the organization's codebase, or from open-source code.
|
||||
|
||||
For example:
|
||||
@ -7,7 +8,6 @@ For example:
|
||||
|
||||
{width=768}
|
||||
|
||||
|
||||
Qodo Merge will examine the code component and will extract the most relevant keywords to search for similar code:
|
||||
|
||||
- `extracted keywords`: the keywords that were extracted from the code by Qodo Merge. the link will open a search page with the extracted keywords, to allow the user to modify the search if needed.
|
||||
@ -19,18 +19,20 @@ Search result link example:
|
||||
|
||||
{width=768}
|
||||
|
||||
|
||||
`Organization Search`:
|
||||
|
||||
{width=768}
|
||||
|
||||
|
||||
## How to use
|
||||
|
||||
### Manually
|
||||
|
||||
To invoke the `similar code` tool manually, comment on the PR:
|
||||
|
||||
```
|
||||
/find_similar_component COMPONENT_NAME
|
||||
```
|
||||
|
||||
Where `COMPONENT_NAME` should be the name of a code component in the PR (class, method, function).
|
||||
|
||||
If there is a name ambiguity, there are two configurations that will help the tool to find the correct component:
|
||||
@ -39,15 +41,19 @@ If there is a name ambiguity, there are two configurations that will help the to
|
||||
- `--pr_find_similar_component.class_name`: in case there are several methods with the same name in the same file, you can specify the relevant class name.
|
||||
|
||||
example:
|
||||
|
||||
```
|
||||
/find_similar_component COMPONENT_NAME --pr_find_similar_component.file=FILE_NAME
|
||||
```
|
||||
|
||||
### Automatically (via Analyze table)
|
||||
|
||||
It can be invoked automatically from the analyze table, can be accessed by:
|
||||
|
||||
```
|
||||
/analyze
|
||||
```
|
||||
|
||||
Choose the components you want to find similar code for, and click on the `similar` checkbox.
|
||||
|
||||
{width=768}
|
||||
@ -56,7 +62,6 @@ You can search for similar code either within the organization's codebase or glo
|
||||
|
||||
{width=768}
|
||||
|
||||
|
||||
## Configuration options
|
||||
|
||||
- `search_from_org`: if set to true, the tool will search for similar code in the organization's codebase. Default is false.
|
||||
|
||||
@ -1,11 +1,12 @@
|
||||
## Overview
|
||||
|
||||
The similar issue tool retrieves the most similar issues to the current issue.
|
||||
It can be invoked manually by commenting on any PR:
|
||||
|
||||
```
|
||||
/similar_issue
|
||||
```
|
||||
|
||||
|
||||
## Example usage
|
||||
|
||||
{width=768}
|
||||
@ -17,15 +18,18 @@ It can be invoked manually by commenting on any PR:
|
||||
Note that to perform retrieval, the `similar_issue` tool indexes all the repo previous issues (once).
|
||||
|
||||
### Selecting a Vector Database
|
||||
|
||||
Configure your preferred database by changing the `pr_similar_issue` parameter in `configuration.toml` file.
|
||||
|
||||
#### Available Options
|
||||
|
||||
Choose from the following Vector Databases:
|
||||
|
||||
1. LanceDB
|
||||
2. Pinecone
|
||||
|
||||
#### Pinecone Configuration
|
||||
|
||||
To use Pinecone with the `similar issue` tool, add these credentials to `.secrets.toml` (or set as environment variables):
|
||||
|
||||
```
|
||||
@ -33,10 +37,11 @@ To use Pinecone with the `similar issue` tool, add these credentials to `.secret
|
||||
api_key = "..."
|
||||
environment = "..."
|
||||
```
|
||||
|
||||
These parameters can be obtained by registering to [Pinecone](https://app.pinecone.io/?sessionType=signup/).
|
||||
|
||||
|
||||
## How to use
|
||||
|
||||
- To invoke the 'similar issue' tool from **CLI**, run:
|
||||
`python3 cli.py --issue_url=... similar_issue`
|
||||
|
||||
|
||||
@ -1,9 +1,12 @@
|
||||
## Overview
|
||||
|
||||
By combining LLM abilities with static code analysis, the `test` tool generate tests for a selected component, based on the PR code changes.
|
||||
It can be invoked manually by commenting on any PR:
|
||||
|
||||
```
|
||||
/test component_name
|
||||
```
|
||||
|
||||
where 'component_name' is the name of a specific component in the PR.
|
||||
To get a list of the components that changed in the PR and choose the relevant component interactively, use the [`analyze`](./analyze.md) tool.
|
||||
|
||||
@ -14,15 +17,14 @@ The tool will generate tests for the selected component (if no component is stat
|
||||
|
||||
{width=768}
|
||||
|
||||
|
||||
(Example taken from [here](https://github.com/Codium-ai/pr-agent/pull/598#issuecomment-1913679429)):
|
||||
|
||||
!!! note "Notes"
|
||||
- The following languages are currently supported: Python, Java, C++, JavaScript, TypeScript, C#.
|
||||
- This tool can also be triggered interactively by using the [`analyze`](./analyze.md) tool.
|
||||
|
||||
|
||||
## Configuration options
|
||||
|
||||
- `num_tests`: number of tests to generate. Default is 3.
|
||||
- `testing_framework`: the testing framework to use. If not set, for Python it will use `pytest`, for Java it will use `JUnit`, for C++ it will use `Catch2`, and for JavaScript and TypeScript it will use `jest`.
|
||||
- `avoid_mocks`: if set to true, the tool will try to avoid using mocks in the generated tests. Note that even if this option is set to true, the tool might still use mocks if it cannot generate a test without them. Default is true.
|
||||
|
||||
@ -1,6 +1,8 @@
|
||||
## Overview
|
||||
|
||||
The `update_changelog` tool automatically updates the CHANGELOG.md file with the PR changes.
|
||||
It can be invoked manually by commenting on any PR:
|
||||
|
||||
```
|
||||
/update_changelog
|
||||
```
|
||||
@ -18,4 +20,4 @@ Under the section `pr_update_changelog`, the [configuration file](https://github
|
||||
- `push_changelog_changes`: whether to push the changes to CHANGELOG.md, or just publish them as a comment. Default is false (publish as comment).
|
||||
- `extra_instructions`: Optional extra instructions to the tool. For example: "Use the following structure: ..."
|
||||
- `add_pr_link`: whether the model should try to add a link to the PR in the changelog. Default is true.
|
||||
- `skip_ci_on_push`: whether the commit message (when `push_changelog_changes` is true) will include the term "[skip ci]", preventing CI tests to be triggered on the changelog commit. Default is true.
|
||||
- `skip_ci_on_push`: whether the commit message (when `push_changelog_changes` is true) will include the term "[skip ci]", preventing CI tests to be triggered on the changelog commit. Default is true.
|
||||
|
||||
Reference in New Issue
Block a user