Skip to content

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: 

[config]
publish_output=false
verbosity_level=2
This is useful for debugging or experimenting with different tools.

(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: 

/review --pr_reviewer.extra_instructions="..." --pr_reviewer.require_score_review=false
Any configuration value in configuration file file can be similarly edited. Comment /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",
    "/review",
    "/improve --pr_code_suggestions.suggestions_score_threshold=5",
]

This means that when a new PR is opened/reopened or marked as ready for review, Qodo Merge will run the describe, review and improve tools.
For the improve tool, for example, the suggestions_score_threshold parameter will be set to 5 (suggestions below a score of 5 won't be presented)

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: 

[pr_description]
generate_ai_title = true
Every time you run the 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]
pr_commands = []

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",
]
This means that when new code is pushed to the PR, the Qodo Merge will run the 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: 

[pr_description]
publish_labels = false
to prevent Qodo Merge from publishing labels when running the 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: 

[gitlab]
pr_commands = [
    "/describe",
    "/review",
    "/improve",
]

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",
]

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: 

[pr_reviewer]
extra_instructions = "Answer in japanese"

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 a 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",
    "/improve --pr_code_suggestions.commitable_code_suggestions=true --pr_code_suggestions.suggestions_score_threshold=7",
]
Note that we set specifically for bitbucket, we recommend using: --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.

To enable BitBucket app to respond to each push to the PR, set (for example): 

[bitbucket_app]
handle_push_trigger = true
push_commands = [
    "/describe",
    "/review",
]

Azure DevOps provider

To use Azure DevOps provider use the following settings in configuration.toml: 

[config]
git_provider="azure"

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: 

[azure_devops_server]
pr_commands = [
    "/describe",
    "/review --pr_reviewer.num_code_suggestions=0",
    "/improve",
]

Footer