Improve branches management for project's repository

[sebalix]

On a project repository, we should get rid of the clone_branch_id field and re-use branch_ids field we already have.
For generic repositories (like OCA) the branch_ids is read-only and populated when modules are scanned, but for specific/project repositories, we should be able to edit this field, and set e.g. a master branch, running a version 16.0, and add another one like 18.0-mig that is running on 18.0. This will require new fields on odoo.branch.

Then, on odoo.project, instead of linking only the underlying odoo.repository this project is based on, we will have to also define the branch (among the repository available branches) to use.

That way we end-up with one cloned project repository and multiple branches fetched in it.

This allows to run a migration scan on these project repositories (work ongoing on oca-port to support any module path here: OCA/oca-port#52) to analyze the gap between the production branch (which could still evolve) and its migration branch.

[hparfr]

In my case, the projects are now following the convention:

• branch 14.0, 16.0, 18.0 ... : main branch per version
• on which branch the production run is not defined in git;
• feature branch: free naming, our ci run against the PR; in the PR we have the info about the target branch - I don't plan to scan these short lived PR.

Specific modules are moved out of the project's local-src and put in a dedicated repo for them. This kind of repo follow most oca practices and use the template https://github.com/OCA/oca-addons-repo-template.git

I plan to use oca-port to this kind of repo; so I adapt / align my practices to what we have on oca.

On a project repository, we should get rid of the clone_branch_id field and re-use branch_ids field we already have.

Yes; + in my case, a project don't "clone" anything.

A project may run in multiple versions at the same time.
The production can be on 16.0 while all the dev effort is targeting 18.0

For generic repositories (like OCA) the branch_ids is read-only and populated when modules are scanned

Yes

but for specific/project repositories, we should be able to edit this field, and set e.g. a master branch, running a version 16.0, and add another one like 18.0-mig that is running on 18.0. This will require new fields on odoo.branch

In my case, I don't need it / it's ok to rename master to 16.0 and follow the practice to have only n.0 main branches.

Then, on odoo.project, instead of linking only the underlying odoo.repository this project is based on, we will have to also define the branch (among the repository available branches) to use.

I propose to change the design to :

Project: 
 - name
 - repository_id
 - default_project_version_id (= prod)

ProjectVersion: (new class)
 - branch_id
 - odoo_project_module_ids (to be renamed into odoo_project_version_module)
-  name  / description

 - use_default_project_version = boolean
 - modules_to_add (many2many odoo_module)
 - modules_to_rm (many2many  odoo_module)

The last 3 fields allow to manage a kind of "wish list" of modules.

For example,

Project: 
-  name: a_super_project
-  repository_id: gh://akretion/a_super_project
-  default_project_version_id : 1

ProjectVersion:
- id: 1
- description:  in production 
- branch_id: 16.0
- odoo_project_version_module: auditlog, web_environnement_ribbon16, web16, base16

ProjectVersion:
- id: 2
- description: experiment what's available
- branch_id: 18.0
- odoo_project_version_module:  web18, base18,
- use_default_project_version: true
- modules_to_add: web_environnement_ribbon
- modules_to_rm: auditlog

(at the moment, web_environnement_ribbon and auditlog are not ready yet for 18.0)
Now, let's wait few weeks; web_environnement_ribbon and auditlog are now migrated and have been scanned.

We now have:

ProjectVersion:
- id: 2
- description: experiment what's available
- branch_id: 18.0
- odoo_project_version_module:  web18, base18, web_environnement_ribbon18
- use_default_project_version: true
- modules_to_add: web_environnement_ribbon
- modules_to_rm: auditlog

we can see, that web_env_ribbon has been added to the list of modules. In that way we can follow how done is a migration.