[14.0] OCA' Odoo instance docker image

[petrus-v]

Here is ongoing work to build OCA' Odoo docker image.

As discussed w/ @sbidoul and the OCA Internal Working Group, here we give a try to include OCA instance project settings to build the images that may be deployed in test/production environment.

We can move that in an independent repository if we needs different maintainers or if it makes confusions ! We through starting here avoid extra repositories and would works as long oca-custom contains (I suppose) module that are only used by OCA ! Anyway I think existing CI/CD shouldn't be that much impacted by this exploration

Tasks

• create module oca_all with all installed modules
• add pyproject.toml create developer python environment using uv and hatch-odoo
• Setup Docker image based on https://github.com/acsone/odoo-bedrock
• Setup github action to build
• In the Dockerfile, add an entry point that runs click-odoo-update (always)

Optionnal/To discuss

• In the Dockerfile, add an entry point that neutralizes the database if we are in a non-prod environment.

• Get exacted module version in odoo database and freeze like in production (I'd like to give a try using latest module version but maybe I'm too reckless !) advices welcomes => let's try with fresh modules
• Install database using the released image before tag it

[sbidoul]

Looks good!

[petrus-v]

@sbidoul I think we are pretty closed to get it.

I'm not sure how to properly build the image that would contains un-merged dependencies, but it's probably better practice to wait to get it merged before deploy in production (I'll try to help there in vertical-association)!!

[sbidoul]

In the Dockerfile, we could add an entry point that runs click-odoo-update (always) and neutralizes the database (if we are in a non-prod environment).

A potential starting point: https://github.com/acsone/acsone-odoo-project-template/blob/master/src/container/entrypoint-dbbase.jinja

[petrus-v]

@sbidoul

and neutralizes the database if we are in a non-prod environment.

odoo neutralizes is availaible from version 16.0, do you mean using @hbrunn's PR OCA/server-backend#346 ?

[petrus-v]

This is not strictly necessary and takes some time likes -u all. This test some how 000_10_odoo-update entry point with a database installed (it not strictly assert that the update has been done). While the -i oca_all test without odoo database!

Any opinion on this?

[sbidoul]

@sbidoul

and neutralizes the database if we are in a non-prod environment.

odoo neutralizes is availaible from version 16.0, do you mean using @hbrunn's PR OCA/server-backend#346 ?

I meant a minimal custom script to disable the crons and mail servers.

Anonymization can come on top but I'd apply that manually?

[petrus-v]

@sbidoul

and neutralizes the database if we are in a non-prod environment.

odoo neutralizes is availaible from version 16.0, do you mean using @hbrunn's PR OCA/server-backend#346 ?

In fact hbrunn's works is about anonymization, not neutralization. So I'm going to start a dedicated script to at least deactivate emails and crons.

And I believes that we should keep neutralisation as sql (likes in later odoo version) in order to execute them before update!

So at the end we will go with: neutralization (if not prod) > update > anonymization (if not prod)

[petrus-v]

I've missed your comment you made before mine, Sorry I'm feeling noisy, sometimes I think loudly... This commit is a proposition to neutralize the database 209f665 Those SQL script cames and are adapted from Odoo 18. I'm wondering if there are some thing to do with github connector, as far I can read github token is in config file so I guess it's safe as long production token wouldn't be in other environements Le lun. 31 mars 2025 à 09:30, Stéphane Bidoul ***@***.***> a écrit :

…

@sbidoul <https://github.com/sbidoul> and neutralizes the database if we are in a non-prod environment. odoo neutralizes is availaible from version 16.0, do you mean using @hbrunn <https://github.com/hbrunn>'s PR OCA/server-backend#346 <OCA/server-backend#346> ? I meant a minimal custom script to disable the crons and mail servers. Anonymization can come on top but I'd apply that manually? — Reply to this email directly, view it on GitHub <#59 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABBAYOZI3R2VDUQRHFEF5632XDVILAVCNFSM6AAAAABZF4VPW6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRVGM2TQMJVG4> . You are receiving this because you authored the thread.Message ID: ***@***.***> [image: sbidoul]*sbidoul* left a comment (OCA/oca-custom#59) <#59 (comment)> @sbidoul <https://github.com/sbidoul> and neutralizes the database if we are in a non-prod environment. odoo neutralizes is availaible from version 16.0, do you mean using @hbrunn <https://github.com/hbrunn>'s PR OCA/server-backend#346 <OCA/server-backend#346> ? I meant a minimal custom script to disable the crons and mail servers. Anonymization can come on top but I'd apply that manually? — Reply to this email directly, view it on GitHub <#59 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABBAYOZI3R2VDUQRHFEF5632XDVILAVCNFSM6AAAAABZF4VPW6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRVGM2TQMJVG4> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- Pierre

[sbidoul]

This is looking good. Thanks a lot for this work!

About the tagging strategy, my usual approach is to create version-like git tags and corresponding image tags. To deploy, it is then just a matter of updating the tag in docker-compose.yml or some associated .env file. And when a version is deemed good for production, do the same update in prod.

That said, I have no real preference on that strategy for the OCA instance, so your proposal is good to me too.

[petrus-v]

I've changed a bit my mind because in my previous messages I was trying to manage 3 concerns:

• *Provides explicit visibility for developers on what's currently deployed in production.
• create release workflow
• document and script the deployment

So I end up with a solution that I've tested on my fork that I feel elegant enough:

• I've discover we can trigger manual workflow from actions panel in github, so I've setup a workflow to bump oca-custom package version (using bump-my-version), assuming we configure a Personnal Access Token https://github.com/OCA-git-bot, ony once could bump the version and push a tag on the HEAD of the selected branch.
• once a tag is pushed CI will build docker image with the same tag

Note: Of course someone allowed to push tag can do it directly a released image will be build as well

To provide explicit visibility for developers on what's currently deployed in production, I'm thinking a way to add environement variable in the docker image and display such value somewhere accessible in odoo.

For deployment, as you suggest, changing version of the docker image in a docker compose file (or .env) and up the project will do the job.

The last missing things here (from my point of view) is the unreleased dependency where I give some helps: OCA/vertical-association#151 which is technically ready to merge but probably needs some attention to make sure what is on the production server !

[sbidoul]

@petrus-v regarding unreleased dependencies, it's probably reasonable to remove this CI check from this repo.

Regarding the release process, why not creating the tags manually? PAT are a kind of security risk and a bit of pain to manage since they expire, so if we can avoid them I tend to prefer.

[petrus-v]

regarding unreleased dependencies, it's probably reasonable to remove this CI check from this repo.

hum... I think we are enough in the group to do reviews and merge PRs before deployment, If needs I'm ready to help on a series of modules/repos to maintains. If we are in the hurry with current workflow we can even push a tag on any commit (even it's not part of the 14.0 branch it should create the docker image.

Regarding the release process, why not creating the tags manually? PAT are a kind of security risk and a bit of pain to manage since they expire, so if we can avoid them I tend to prefer.

I wanted to change the version in the pyproject.toml which require to push commit on 14.0 branch, this is not strictly required. Also I was wondering who are able to push tag in the repository ?

While it's not recommend it's possible to create PAT without expiration !

I guess people that get access to push tag won't get access push access to the 14.0 branch so I can get ride of the manual workflow and the bump-my-version configuration from this PR?

I've removed the manual step that would have require PAT (Personal Access Token), bump my version configuration and update the release documentation by this commit 79512d3

[petrus-v]

@sbidoul

• This commit 1b2ef6a ignore un-released dependencies as you suggested earlier, but I'm wondering the impacted on the released process, notably if we add dependency to a new module that won't be present on pypi - it's the case here-, as far I remember we can't publish a module on pypy package that dependents on something that is not released?

• This commit d8ae21d use the PR [14.0][FIX] change membership product on invoice line OCB#1299, I haven't deep into to make sure runboat do not use the PR on OCA/OCB repo as odoo code source (cf comment) but could be nice to go ahead on this topic add a tag and release a version to deploy on a staging environment that Virginie and Rebacca could tests what we do. An Image is ready on my fork docker pull ghcr.io/petrus-v/oca-custom:v14.0.20250604. The Idea would be to merge here and add a tag in this repo to run the release pipeline and publish the docker image here !

• This commit 07c3680 revert using OCB's PR in this repo CI as it makes runboat error, but keep it in the released image : this makes a difference between what's tested and what's released, I'm starting to considering to create a different repository or improve the tool chain (that could be done later if we really have a dependency in unittest or want test happens on runboat). Also those issue could be mitigate by finding a way to improve reviews in the workgroup (I'll probably suggest ideas on this topic by email).

• while doing this I've open a proposal on odoo-bedrock here: Early faillure while running custom entry-points acsone/odoo-bedrock#53 seen in this build ;) I've to investigate a bit more why CI sudently failled to see postgresql service which was not the case on this commit d8ae21d... 🤯

Any comment welcome :)

ps: If I can help with admin sys tasks I could help if needs.

[sbidoul]

impacted on the released process

There might be something in the bot to prevent the publishing of some addons, or the whole repo. I'll need to check.
At least oca_all does not make sense for publishing.

I'll find a moment to deploy this on test.odoo-community.org.

[petrus-v]

I"ve squashed some commits to get a cleaner history !

[sbidoul]

@petrus-v I sent petrus-v#1 with a few minor tweaks, and deployed on https://test.odoo-community.org.

The docker compose currently builds from a local clone of this branch.

All looks good. Thanks for this work!

[sbidoul]

@petrus-v shall we merge this?

[petrus-v]

@sbidoul I think the latest point without responses here is regarding build and publish process with some unreleased dependencies that may crash the publish CI pipeline that you know more than me.

Otherwise this seems working on test environment so I'm in favour to merge it !