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!