Repository navigation
Rename repository and modules #137
Description
Activity
because the main logic would already be in github_connector.
because the main logic would already be in git_connector.
I guess.
Otherwise, totaly agree with such move.
Reacted by Víctor MartínezYes, I think we should start renaming the repository to interface-git (the previous names remains as an alias, so no compatibility problem), then I would like to get rid of
connectorword, as this is not using such modules for "connecting" to GitHub, sogit_interface,git_interface_odoocan be possible names.I agree with @pedrobaeza to rename it to interface-git.
@victoralmau I don't think we should create a generic git_interface module. In my experience Github and Gitlab work very different for example in gitlab there is a group hierarchy where the top on is considered the organization. This is not case for Github where you only have a organization. In Github pull requests are issues, in gitlab those are separate things. In Github the Github user is included in commits but in Gitlab not.
Well, all that things can be tackled in an abstract way IMO. For example, organizations can have an optional parent field. The other things you mention right now are not handled in GitHub modules and are not the current goal. The idea of merging both is for using standard git to get code, previously getting basic structure (organizations and repos) from each API, and finally analyzing code the same way coming from one system or another.
Okay, then a generic module can be made for the git operations, which can also include basic structure also that most git hosting platforms have. But my goal is not to pull in the code of repositories, I just want to have the issues, pull requests, and commit information.
Either way, for the meantime can we rename this repo to interface-git? So I can house the gitlab module here (OCA/server-backend#413)
Well.
- 👍 to rename interface-github to interface-git and put all git / gitlab / github modules here. (like a verticalisation).
- not sure about abstract modules that could host generic concept. I let developpers decide if making generic things is easy / feasable / interesting. (note : I don't use anymore github modules I developped)
Can we proceed with this or does it need more opinions?
OK for me !
I would appreciate that!
- added a commit that references this issue
on Feb 13, 2026 @etobella I'm not able to rename the repository. Can you please do it?
I have opened OCA/repo-maintainer-conf#132 for handling the part of the repository OCA configuration. It should be merged after renaming the repo.
Thanks @pedrobaeza @victoralmau
Just a silly question, this seems quite similar to me to OCA/version-control-platform#3
Maybe we can find a common ground and converge in a single solution. WDYT?
Yes, that new repository was out of our radar. This one is older, and look for the same principles, and more with the planned refactoring. Is your development already deployed? Can we converge adding the missing features here?
Hi, if we can converge it's the best option.
Right now we have quiet a lot of duplicated feature, so converging is always good !
To keep in mind we have
- https://github.com/OCA/version-control-platform (VCP) => Generic module for interacting with version control plateform like, github / gitlab (not yet implemented)
- https://github.com/OCA/module-composition-analysis (MCA) => the aim is to analyse your odoo project to organise/supervise the migration (really really interesting project)
Also (I want to move this to OCA, short/long story, I was waiting for MCA to be in OCA for doing it, now I will wait that we all converged before ;) ). https://github.com/akretion/partner-module-information.
Mostly this set of module are here to track OCA PR to see which PR impact which project so you can- dispatch and organise your team to work on PR
- timesheet your time on PR
- show to your customer the time spend on PR so you can justify the maintenance cost.
If we want to converge on this topic, we need to find the right granularity to avoid reinventing the wheel because current modules are too big. @sebalix is ok that MCA can depend on VCP to avoid reimplementing the logic of repo/orga...
I think, it's interesting to take a look to what have been done by @etobella
He have done the following module
vcp : base module to manage Version Control Plateform (can be git based or something else)
vcp_github : Implementation with github API
vcp_portal : Integrate VCP data to the portail
vcp_website : Integrate VCP with websiteThe idea behind this module is to be able to build application on top (like integration with your project management, manage PR...)
I like the naming (it's short and not related to git).For all of this module there is not logic of downloading the code, this should be done in a separated module (ex: you do not need to clone your code if you want to integrate gitlab PR with your project management)
@victoralmau what are you use case ? What is your idea behind this refactor ? What do you think about using @etobella module as dependencies ?
Also for OCA instance (in order to get contributor statistic) we need to have the VCP working on 18. So it can be great if we can converge on 18.0 (even on an not official branch to not break existing installation, then we can use this branch to migrate to 19.0)
Do you think it's possible ?
Hi!
Well, my module is not deployed in a production system, so we can decide what to do (right now is the best moment for it).
From what I see we could do something like:
vcp: Core module that defines organization, branch, repository, pull requests, comments ... We might need other modules in the future if necessary. We should define some function that will be implemented later and used in other modules to avoid extra glue modules, like _get_file or _get_folders in vcp.repositoryvcp_github: Link with Githubvcp_gitlab: Link with Gitlabvcp_odoo: Imports modules an implements a new model called vcp.odoo.module. Here is where we should define the rules to decide which branches are used to define this modules- Other VCP Modules that we already did, like Weblate or website integration
Just to be clear, I used vcp but we can decide another name if you want.
From my perspective, this addons is in 18 and we cannot change it right now, however, we have the opportunity to make it together in 19. So, my proposal is to make it in 18 and prepare all the necessary migration scripts and make a migration path (even in 18 if we make some kind of scripts that can be executed from the terminal). From a general perspective, if we keep vcp in the name we can use version-control-platform repository and archive this in a few years. WDYT?
I probably need to make a better review of each model and check where it fits, but it looks like a promising plan to me.
If you want, I can start from this point and try to find a way to handle it all together.
Reacted by beau sebastien@etobella seem to be a good plan for me ;)
Good for me too even in 18, if we can add all the Odoo module extraction + code analysis that is in the other modules.
Hi all,
I am interested in contributing to this effort.
This is actually a feature I need in one of my own projects as well, so I have a strong interest in seeing it move forward and would be happy to contribute both time and development work to make it happen.
After going through the discussion, it seems that aligning around VCP is the most sensible long-term direction. Before I start digging into the implementation, I would like to confirm whether that is still the preferred approach and get a better understanding of the current expectations, priorities, and scope.
If the direction is still the same, I am happy to help with the analysis, identifying gaps between the current implementation and VCP, defining a migration path, and contributing to the actual development work.
Looking forward to your feedback and to collaborating on this.
@pedrobaeza @etobella @sebastienbeau @legalsylvain @victoralmau @tarteo
@BhaveshHeliconia we did the Version-Control-Platform that makes something similar and inherits most of the functionalities that we talked about. I recommend you to review it.
@etobella Thanks for the pointer.
Yes, I have been reviewing VCP and its current functionality. My understanding is that it already provides most of what was discussed in this thread.
In that case, would the preferred approach be to build the missing pieces directly on top of VCP and target Odoo 19 instead of continuing with a separate implementation?
I will continue reviewing the codebase and the existing features to identify any gaps and understand the scope of the work.
Thinking especially in v19 I think it would be appropriate to take advantage of the migration of the modules to rename them properly, I think the right approach would be:
github_connector: it would be renamed togit_interface. All models and field names containing “github” should be renamed to “git”. ThePyGithubdependency of the module would be removed. A field (git_source) would be added (e.g. in organizations) to indicate the source (github/gitlab, etc).git_interface_github: ThePyGithubdependency would be added and what “github_connector” currently has regarding the connection to github would be moved.github_connector_odoo: It would be renamed togit_interface_odooand would only have thegit_interfacemodule dependency.This approach would allow to add other sources and create for example a new
git_interface_gitlabmodule that would allow to add the gitlab organizations/repositories/modules “with almost no effort” because the main logic would already be ingit_interface.For consistency with all this, a new OCA/interface-git repository (or similar) should be created to move the modules in v19 to that repository.
What do you think?
Ping @pedrobaeza