Allow specifying a custom branch for locating `.pr_agent.toml`

[alvarogl]

Feature request

Add an option to control which Git branch the tool inspects when searching for the .pr_agent.toml configuration file. By default, the tool currently only looks in the repository’s default branch (e.g. main or master). We’d like to be able to override this—either via:

• A CLI flag (e.g. --config-branch <branch-name>),
• An environment variable (e.g. PR_AGENT_CONFIG_BRANCH),
• Or by falling back to the PR’s source branch before the default branch.

When provided, the tool should attempt to load .pr_agent.toml from the specified branch; if the file is not found there, it can then fall back to the default behavior or emit a clear warning/error.

Motivation

• Isolated experimentation: When testing new models, fine-tuning parameters, or iterating on configuration, it’s useful to keep those experimental files on a feature branch rather than clutter the main branch.
• Clean default branch: Prevents temporary or exploratory configuration files from being merged into the primary branch, reducing merge noise and accidental commits.
• Flexible workflows: Teams may have multiple environments (staging, QA, production) represented by different branches; being able to point PR-Agent at the correct branch config makes it easier to mirror real-world conditions.
• Consistency with other tools: Many CI/CD and build systems allow overriding the config branch; providing the same flexibility here aligns PR-Agent with existing developer expectations.

[qodo-merge-for-open-source]

💡 Auto-generated documentation-based answer:

Based on the current documentation, this feature request is not currently supported by PR-Agent/Qodo Merge. The documentation shows that configuration files are loaded from specific, fixed locations:

Current Configuration File Locations

PR-Agent currently supports three types of configuration files, all loaded from predetermined locations:

1. Local configuration file: .pr_agent.toml in the root of the repo's default branch
2. Wiki configuration file 💎: .pr_agent.toml page in the repository wiki
3. Global configuration file 💎: .pr_agent.toml in a pr-agent-settings repository within the organization

Current Limitations

The documentation explicitly states that for local configuration files, you need to "upload .pr_agent.toml to the root of the repo's default branch" and that "you need to upload or update .pr_agent.toml before using the PR Agent tools for the configuration to take effect."

Feature Request Status

Your requested feature to specify a custom branch for locating .pr_agent.toml via:

• CLI flags (e.g., --config-branch <branch-name>)
• Environment variables (e.g., PR_AGENT_CONFIG_BRANCH)
• Fallback to PR's source branch

This functionality is not currently available and would need to be implemented as a new feature.

Current Workarounds

For experimentation and testing different configurations, you could currently:

1. Use wiki configuration 💎 (if available) - allows editing configuration without committing to the repo
2. Use command-line parameter overrides for temporary testing:

   /review --pr_reviewer.extra_instructions="..." --pr_reviewer.some_config=value
   

3. Temporarily commit configuration changes to the default branch for testing (though this doesn't address your "clean default branch" motivation)

This appears to be a valid feature request that would enhance PR-Agent's flexibility for the use cases you've described.

Relevant Sources:

• https://qodo-merge-docs.qodo.ai//usage-guide/configuration_options#local-configuration-file
• https://qodo-merge-docs.qodo.ai//usage-guide/configuration_options#wiki-configuration-file
• https://qodo-merge-docs.qodo.ai//usage-guide/configuration_options#global-configuration-file
• https://qodo-merge-docs.qodo.ai//usage-guide/automations_and_usage#online-usage

[mrT23]

Wiki is suitable for experimentation like this. It is supported in Qodo Merge.

You are offering a param PR_AGENT_CONFIG_BRANCH that will define a branch with the configuration file.
But how will you define this param ? in a ... configuration file. That pr-agent needs to know where it is.
So it problematic

[alvarogl]

I understand that option might be a little tricky.
However, the CLI flag might be optional and no extra changes in configuration files would be needed.
The code providers could just read that property if present. Else, fallback to default branch.