Allow addon maintainers to ocabot merge migration PRs

[sbidoul]

First thing is to write down the algorithm...

[legalsylvain]

Hi @sbidoul : I'm very interested by this one. I don't know how to implement it however.

Use case :

• I developed a module named account_template_active in https://github.com/OCA/account-financial-tools (branch 12.0). link
• Someone port this module in V14.0. ([14.0.0][MIG] account_template_active account-financial-tools#1187)
• I'd like to merge the PR once the approval process is done.

Different approaches at the first sight :

1. git fetch various previous branches (13.0, 12.0, 11.0, ...), until founding a branch that contain an installable module name account_template_active. Check if the user that call ocabot merge is the maintainer of the latest version of the module.
2. Call github and wget https://github.com/OCA/account-financial-tools/blob/XX.0/account_template_active/__manifest__.py files and check if the manifest contains the author of the call.
3. Call via API, odoo-community.org. (not sure, it seems that somebody said me it was not possible). (BTW, it seems that the instance doesn't fetch latest modules because the module account_template_active is not available on OCA website)
4. Other ?

[joao-p-marques]

Cool 👍 This would, indeed, be very helpfull... There would still be some cases the bot wouldn't pick up (when it is renamed or moved to a different repo) but it would still cover the majority of the cases and would already be of great help.

Option 1 gived by @legalsylvain seems to be the easiest one

[legalsylvain]

thanks @joao-p-marques for your review.

@sbidoul, @pedrobaeza : any point of view regarding the different possibilities ?

[pedrobaeza]

As I don't know the internals of how this is done, I can't say which one is the best approach, but it seems the third option is not very feasible. I see the number 1 as the way to go.

[sbidoul]

Yep, 1 or 2.

Option 2 (with requests.get) is probably faster and since it is not the API it should not be sensitive to API rate limits.

[pedrobaeza]

Cool, then 2 is lighter