I've spent quite a lot of time working with Odoo, Git repositories and project-management systems, and eventually the same problem kept appearing:
Why are my project tasks and my development work living in completely different places?
Odoo is where I often want the project itself to live. GitHub or GitLab is where the code lives. Pull requests have their own discussions. Issues have their own comments. And if you're using something like YouTrack, there's another system involved again.
So I decided to build something to connect them.
That project is the Odoo DevOps Project Bridge.
The idea
The concept is fairly simple.
Take an Odoo project and connect it to an external DevOps platform, then allow information to move in both directions.
At the moment the project is designed around three providers:
- GitHub
- GitLab
- JetBrains YouTrack
Rather than trying to turn Odoo into a Git hosting platform, the Bridge leaves each system doing what it is good at.
Odoo handles the project-management side.
GitHub, GitLab or YouTrack handles the development and issue-management side.
The Bridge connects the two.
Making synchronisation actually two-way
The important word here is bidirectional.
It isn't just an Odoo button that says "send this task to GitHub".
A task can be created or updated in Odoo and synchronised to the remote system, while changes made remotely can come back into Odoo.
Comments are part of this as well, so the Odoo chatter and the remote issue discussion can stay connected.
That introduces one of those wonderfully annoying problems that only appears once you start building the thing: recursion.
If Odoo updates GitHub, GitHub sends a webhook back to Odoo, and Odoo then updates GitHub again, you have built yourself a tiny distributed-system version of two mirrors shouting at each other.
The Bridge therefore includes a recursion guard to stop synchronisation loops.
Authentication was more interesting than expected
Another part I wanted to get right was user identity.
It would have been easy to make the module use one token for everything. From a technical perspective, that would simplify quite a lot.
It would also mean that every action effectively came from the same account.
Instead, the Bridge allows an administrator to configure the DevOps servers while individual Odoo users provide their own Personal Access Tokens.
That means an action performed through Odoo can still be associated with the developer who actually performed it.
There is also support for a bot or service account as a fallback for automated work such as webhook processing and scheduled synchronisation.
This gives the module a useful distinction between "I performed this" and "the system performed this automatically".
Webhooks make it feel much more like a real integration
The Bridge uses webhooks to receive changes from the external platforms.
Rather than having Odoo constantly ask GitHub or GitLab whether anything has changed, the external service can tell Odoo when something happens.
There is also fallback polling through an optional scheduled job, because webhooks are wonderful right up until one gets lost.
When something does go wrong, the Bridge keeps an audit trail of synchronisation events, including the payload and response. Events can then be replayed for troubleshooting.
That part has been particularly important to me because integrations are much easier to debug when you can actually see what happened.
Pull requests in Odoo
One of the more interesting parts of the module is the pull/merge request tracking.
A software project isn't just a list of tasks.
Eventually those tasks turn into branches, commits and pull requests, and the pull request itself becomes a significant part of the work.
The Bridge therefore gives pull and merge requests their own Odoo views, with information such as branches, review information and diff statistics.
It also understands references between development work and Odoo tasks, so the relationship between "what are we doing?" and "what code actually implements it?" doesn't have to disappear into a GitHub tab.
Building it properly as an Odoo module
The project started using the standard Odoo app teamplate from Toasty Software.
It then grew fairly quickly.
The initial structure was followed by the webhook controllers, security and scheduled data, Odoo models, provider services, synchronisation wizard, views and tests.
As of now, version 0.2.0 is ready.
That release contains the main functionality needed to start deploying and testing the Bridge rather than simply looking at an empty module skeleton.
There is still plenty to do, particularly around polishing the different provider integrations, but it has reached a point where the architecture is much more tangible.
And then Odoo 20 arrived
Of course, Odoo 20 arrived right in the middle of all of this.
The Bridge is therefore also beginning its transition towards Odoo 20 support.
For now, Odoo 19 remains the main supported version, while the Odoo 20 work begins alongside it. This is also giving me a useful real-world project on which to work through some of the changes between Odoo versions.
It's a rather appropriate project for that, considering its entire purpose is connecting different systems together.
Where it goes next
The long-term idea is bigger than simply synchronising GitHub issues.
I'd like the Bridge to become a proper development-management layer inside Odoo: something that can connect projects, tasks, issues, pull requests, discussions and automation without forcing the developer to abandon the tools they already use.
There are still plenty of details to work through before it gets there.
GitLab and YouTrack need continued attention, the Odoo 20 implementation needs to mature, and the documentation and deployment experience will continue to improve.
But version 0.2 is a good point to stop looking at it as just an experiment.
It is now a real project.
And, as with most of my projects, it started with a fairly simple thought:
Surely I can make this a little less annoying.
The project
The Odoo DevOps Project Bridge is open source and available my GitLab: