Usage and Automation
Local repo (CLI)¶
When running from your locally cloned Qodo Merge repo (CLI), your local configuration file will be used. Examples of invoking the different tools via the CLI:
- Review:
python -m pr_agent.cli --pr_url=<pr_url> review
- Describe:
python -m pr_agent.cli --pr_url=<pr_url> describe
- Improve:
python -m pr_agent.cli --pr_url=<pr_url> improve
- Ask:
python -m pr_agent.cli --pr_url=<pr_url> ask "Write me a poem about this PR"
- Reflect:
python -m pr_agent.cli --pr_url=<pr_url> reflect
- Update Changelog:
python -m pr_agent.cli --pr_url=<pr_url> update_changelog
<pr_url>
is the url of the relevant PR (for example: #50).
Notes:
(1) in addition to editing your local configuration file, you can also change any configuration value by adding it to the command line:
python -m pr_agent.cli --pr_url=<pr_url> /review --pr_reviewer.extra_instructions="focus on the file: ..."
(2) You can print results locally, without publishing them, by setting in configuration.toml
:
(3)
git provider: The git_provider field in a configuration file determines the GIT provider that will be used by Qodo Merge. Currently, the following providers are supported:
"github", "gitlab", "bitbucket", "azure", "codecommit", "local", "gerrit"
Default is "github".
Online usage¶
Online usage means invoking Qodo Merge tools by comments on a PR. Commands for invoking the different tools via comments:
- Review:
/review
- Describe:
/describe
- Improve:
/improve
(or/improve_code
for bitbucket, since/improve
is sometimes reserved) - Ask:
/ask "..."
- Reflect:
/reflect
- Update Changelog:
/update_changelog
To edit a specific configuration value, just add --config_path=<value>
to any command.
For example, if you want to edit the review
tool configurations, you can run:
/config
to see the list of available configurations.
GitHub App¶
Configurations for Qodo Merge Pro
Qodo Merge Pro for GitHub is an App, hosted by CodiumAI. So all the instructions below are relevant also for Qodo Merge Pro users. Same goes for GitLab webhook and BitBucket App sections.
GitHub app automatic tools when a new PR is opened¶
The github_app section defines GitHub app specific configurations.
The configuration parameter pr_commands
defines the list of tools that will be run automatically when a new PR is opened.
[github_app]
pr_commands = [
"/describe --pr_description.final_update_message=false",
"/review --pr_reviewer.num_code_suggestions=0",
"/improve",
]
describe
, review
and improve
tools.For the
review
tool, for example, the num_code_suggestions
parameter will be set to 0.
You can override the default tool parameters by using one the three options for a configuration file: wiki, local, or global.
For example, if your local .pr_agent.toml
file contains:
describe
tool, including automatic runs, the PR title will be generated by the AI.
To cancel the automatic run of all the tools, set:
GitHub app automatic tools for push actions (commits to an open PR)¶
In addition to running automatic tools when a PR is opened, the GitHub app can also respond to new code that is pushed to an open PR.
The configuration toggle handle_push_trigger
can be used to enable this feature.
The configuration parameter push_commands
defines the list of tools that will be run automatically when new code is pushed to the PR.
[github_app]
handle_push_trigger = true
push_commands = [
"/describe",
"/review --pr_reviewer.num_code_suggestions=0 --pr_reviewer.final_update_message=false",
]
describe
and review
tools, with the specified parameters.
GitHub Action¶
GitHub Action
is a different way to trigger Qodo Merge tools, and uses a different configuration mechanism than GitHub App
.
You can configure settings for GitHub Action
by adding environment variables under the env section in .github/workflows/pr_agent.yml
file.
Specifically, start by setting the following environment variables:
env:
OPENAI_KEY: ${{ secrets.OPENAI_KEY }} # Make sure to add your OpenAI key to your repo secrets
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} # Make sure to add your GitHub token to your repo secrets
github_action_config.auto_review: "true" # enable\disable auto review
github_action_config.auto_describe: "true" # enable\disable auto describe
github_action_config.auto_improve: "true" # enable\disable auto improve
github_action_config.pr_actions: ["opened", "reopened", "ready_for_review", "review_requested"]
github_action_config.auto_review
, github_action_config.auto_describe
and github_action_config.auto_improve
are used to enable/disable automatic tools that run when a new PR is opened.
If not set, the default configuration is for all three tools to run automatically when a new PR is opened.
github_action_config.pr_actions
is used to configure which pull_requests
events will trigger the enabled auto flags
If not set, the default configuration is ["opened", "reopened", "ready_for_review", "review_requested"]
github_action_config.enable_output
are used to enable/disable github actions output parameter (default is true
).
Review result is output as JSON to steps.{step-id}.outputs.review
property.
The JSON structure is equivalent to the yaml data structure defined in pr_reviewer_prompts.toml.
Note that you can give additional config parameters by adding environment variables to .github/workflows/pr_agent.yml
, or by using a .pr_agent.toml
configuration file in the root of your repo
For example, you can set an environment variable: pr_description.publish_labels=false
, or add a .pr_agent.toml
file with the following content:
describe
tool.
GitLab Webhook¶
After setting up a GitLab webhook, to control which commands will run automatically when a new MR is opened, you can set the pr_commands
parameter in the configuration file, similar to the GitHub App:
the GitLab webhook can also respond to new code that is pushed to an open MR.
The configuration toggle handle_push_trigger
can be used to enable this feature.
The configuration parameter push_commands
defines the list of tools that will be run automatically when new code is pushed to the MR.
[gitlab]
handle_push_trigger = true
push_commands = [
"/describe",
"/review --pr_reviewer.num_code_suggestions=0 --pr_reviewer.final_update_message=false",
]
Note that to use the 'handle_push_trigger' feature, you need to give the gitlab webhook also the "Push events" scope.
BitBucket App¶
Similar to GitHub app, when running Qodo Merge from BitBucket App, the default configuration file from a pre-built docker will be initially loaded.
By uploading a local .pr_agent.toml
file to the root of the repo's main branch, you can edit and customize any configuration parameter. Note that you need to upload .pr_agent.toml
prior to creating a PR, in order for the configuration to take effect.
For example, if your local .pr_agent.toml
file contains:
Each time you invoke a /review
tool, it will use the extra instructions you set in the local configuration file.
Note that among other limitations, BitBucket provides relatively low rate-limits for applications (up to 1000 requests per hour), and does not provide an API to track the actual rate-limit usage.
If you experience lack of responses from Qodo Merge, you might want to set: bitbucket_app.avoid_full_files=true
in your configuration file.
This will prevent Qodo Merge from acquiring the full file content, and will only use the diff content. This will reduce the number of requests made to BitBucket, at the cost of small decrease in accuracy, as dynamic context will not be applicable.
BitBucket Self-Hosted App automatic tools¶
To control which commands will run automatically when a new PR is opened, you can set the pr_commands
parameter in the configuration file:
Specifically, set the following values:
[bitbucket_app]
pr_commands = [
"/review --pr_reviewer.num_code_suggestions=0",
"/improve --pr_code_suggestions.commitable_code_suggestions=true --pr_code_suggestions.suggestions_score_threshold=7",
]
--pr_code_suggestions.suggestions_score_threshold=7
and that is the default value we set for bitbucket.
Since this platform only supports inline code suggestions, we want to limit the number of suggestions, and only present a limited number.
Azure DevOps provider¶
To use Azure DevOps provider use the following settings in configuration.toml:
Azure DevOps provider supports PAT token or DefaultAzureCredential authentication. PAT is faster to create, but has build in expiration date, and will use the user identity for API calls. Using DefaultAzureCredential you can use managed identity or Service principle, which are more secure and will create separate ADO user identity (via AAD) to the agent.
If PAT was chosen, you can assign the value in .secrets.toml. If DefaultAzureCredential was chosen, you can assigned the additional env vars like AZURE_CLIENT_SECRET directly, or use managed identity/az cli (for local development) without any additional configuration. in any case, 'org' value must be assigned in .secrets.toml:
[azure_devops]
org = "https://dev.azure.com/YOUR_ORGANIZATION/"
# pat = "YOUR_PAT_TOKEN" needed only if using PAT for authentication
Azure DevOps Webhook¶
To control which commands will run automatically when a new PR is opened, you can set the pr_commands
parameter in the configuration file, similar to the GitHub App: