Freezing Odoo on commit level

[ska-ibees]

Hi Doodba community,

Just wanted to know how you deal with the ever-changing Odoo core code?
Well, as git-aggregator is in place in doodba and /custom/src/odoo is also git ignored. So, odoo core is being cloned frequently e.g. during each project build and/or CI/CD cycle.

Do you think it is safe to keep odoo remote on the branch level in repos.yaml? Or it would be better to freeze odoo core at the commit level and use the same code base throughout your project lifecycle with manual upgrades?

[pedrobaeza]

A freeze is not generally needed, and less even on Odoo core, as Odoo's stability policy avoids any breaking change (https://github.com/odoo/odoo/wiki/Contributing#what-does-stable-mean). For OCA, you have also guaranteed a "migration path" to latest version. You just need to upgrade your modules in the DB.

Anyway, if you want to make a freeze, just define a specific commit in repos.yaml file and there will be.

[ska-ibees]

Got impacted by odoo/odoo@be2c857 where I was using

request.httprequest.app in a custom rewrite module.

Got outage on production as it is nearly impossible to locally re-build image after each update and to test the whole thing every time.

I think it is time to freeze Odoo core on a certain commit and have an upgrade plan in place to adopt any future enhancements/bug fixes.

[ska-ibees]

Silly thing to ask, but could you please share syntax of repos.yaml where we can specify certain commit?

[yajo]

See https://github.com/acsone/git-aggregator/#configuration-file

[pedrobaeza]

That's a very bad idea, as you wouldn't benefit of security patches (and other bugfixes) that land from now on, and the rest of the OCA modules may fail if they expect latest Odoo code. Take into account that although is true something might rarely be broken after an update, there are 2 things:

1. The more hackish the method you put, the more chances of being broken, so do things the right way and avoid certain danger stuff. What you comment about rewriting the HTTP request stack sounds like these dangerous practices.
2. Anyways, if no other way, include tests that assure the behavior you want, so any problem is detected automatically not by you, but any CI doing this automatically, and fix it when happen, and meanwhile, don't deploy new stuff.

BTW, you can do such freeze putting:

./odoo:
  defaults:
    depth: 500  # For assuring certain margin. This may fail if Odoo pushes more commits during time
  remotes:
    odoo: https://github.com/odoo/odoo.git
  target: odoo $ODOO_VERSION
  merges:
    - odoo <sha_of_the_last_commit> # previous to the change you want to avoid

[ska-ibees]

Appreciate your kind response.

Yes, I totally agree to keep going with regular updates. That's why I mentioned about some scheduled updates rather having code updated on every image re-build.

1. The more hackish the method you put, the more chances of being broken, so do things the right way and avoid certain danger stuff. What you comment about rewriting the HTTP request stack sounds like these dangerous practices.

Agreed. It was a nececssity as Odoo is still unable to provide freedom to have fully custom website URLs(without having any record ids etc.) . From SEO point of view it is mandatory to keep URLs as is... That's why I used OCA's website_seo_redirection. So, it is something I need to carry on in the future as well. I hope Odoo's current develoment with http layer brings such freedom where we can set a custom URL...

2. Anyways, if no other way, include tests that assure the behavior you want, so any problem is detected automatically not by you, but any CI doing this automatically, and fix it when happen, and meanwhile, don't deploy new stuff.

Yes, it should be the way to go.

BTW, you can do such freeze putting:

./odoo:
  defaults:
    depth: 500  # For assuring certain margin. This may fail if Odoo pushes more commits during time
  remotes:
    odoo: https://github.com/odoo/odoo.git
  target: odoo $ODOO_VERSION
  merges:
    - odoo <sha_of_the_last_commit> # previous to the change you want to avoid

Thanks again!

[TheerayutEncoder]

Dear @pedrobaeza

On my server, I run odoo using doodba-copier template for production (prod.yaml)
I just noticed that if I don't change any code on github repository when I run
docker-compose -f prod.yaml up -d --build
it does not trigger git-aggregate

could you suggest in case I just want to update the latest code from OCA which is declared in repos.yaml

merges:
    - odoo $ODOO_VERSION
    - odoo refs/pull/<PR>/head

Best regards

[pedrobaeza]

docker compose build --pull --no-cache, and then docker compose up -d.

[ap-wtioit]

if you have an already built image on your local system, docker build uses the previous image layers when building the new image. there is the option to disable the cache when using docker compose build:

docker compose -f prod.yaml build --no-cache && docker compose -f prod.yaml up -d

(and please use docker compose instead of docker-compose in 2025)

if you want to continue using your command you also can add the current date to repos.yaml or addons.yaml before building (or create a custom marker file in odoo/custom/src):

echo "# build now $(date)" >> odoo/custom/src/addons.yaml

[TheerayutEncoder]

Thanks @pedrobaeza and @ap-wtioit

This worked fine.