What's the recommended approach for sharing the pr_agent.toml file with multiple Repos?

[LawrenceMantin]

Our company has many Azure DevOps repos that I would like to use the same pr_agent.toml file to maintain consistency and reduce redundancy. What's the recommended approach, and are there any examples of azure-pipeline to make this work? Thanks.

[gaeljw]

Interested in this as well, in a GitLab CI webhook context.

I was considering the easiest might be a dedicated instance of PR-agent per group of configurations with configurations set at the instance level rather than in repositories. This might not be affordable to everyone though and has it's own challenges.

Ideally, there could be some kind of inheritance in a similar manner to how RenovateBot does it: each config file in a repo can reference another repo and automatically includes its configurations.

---

Another approach, if you running PR agent through a CI pipeline is to set the config in the pipeline rather than in config file and I guess you can have some kind of "includes" to import a shared job definition in Azure DevOps? This is a guess, I don't know Azure but this is something that would be doable in GitLab CI.

[steve-orbussoftware]

If a repo is created using the recommended naming (pr-agent-settings) and a .pr_agent.toml file is located within it, why can't the qodo agent pull that config from that repo? Provided the PAT has sufficient permissions to read that repo of course.

Is there a blocking problem or it's just not implemented, @mrT23 ?

[DanaFineTLV]

Hi @steve-orbussoftware @gaeljw @LawrenceMantin , thank you so much for adding those questions.
We are restructuring the project, and starting from next week, community maintainers will be involved. I apologize for the delay in my response.
If you're interested in actively participating in the project maintenance, please reach out to me via email at [email protected] or on LinkedIn - https://www.linkedin.com/in/fine-dana/

[LawrenceMantin]

@steve-orbussoftware Instead of trying to share the pr_agent.toml file, we took the approach of using environment variables within our pipeline. This pr_agent job is configured to be a template so that it can be referenced from other pipelines. However, the pr_agent is spun up each time the pipeline runs, so I feel that it looses context for each follow-up commit. I have a ticket open with Qodo to see if there's a better approach (i.e. hosting it in our own container), but still waiting for a response.

[steve-orbussoftware]

Nice! We use a shared set of central templates in this same way, and had planned to make this a reusable step. I hadn't considered piping in the config as vars instead of using the toml, that does indeed solve the problem.

As for central hosting: I had assumed that was going to be needed to be able to utilize a webhook based trigger system for the PRs. I would very much prefer to get to a solution where there's a central service running that is triggered by PR webhooks and contributes to the PR, rather than needing to define a pipeline per repo that runs. We have similar services interacting in that way. Might be a stretch at the moment though.