[DRAFT] [RFD]: Does Doodba as a base still make sense for us?

[theangryangel]

This is a draft tracking issue/note-taking only at this point. It will be adjusted into an appropriate format.

---

• Doodba serves us very well, it generally just works, but it is:

  • Different vs the standard Odoo container, which has confused other partners. Can we get it closer?
  • Does a lot of clever stuff, some of which we don't need
  • In the very very rare occasion when there's a problem, we need to work-around them
  • Does a lot more in python when there are other tools, like envsubst, run-parts, etc. that perhaps might be better suited
  • Some Glo team members struggle with some of the complexities
  • There's stuff in the base image we don't care about, can we shrink it?

• We spend a lot of CI minutes on tests, etc. can we speed things up?

  • Can we speed up build at all?
  • Can we speed up tests?

• Pulling images on Azure can be quite slow sometimes due to their size. It seems inconsistent and probably hub.docker.com to blame. Can we shrink things?

Unorganised thoughts:

• Rather than having any base, we could just template the Dockerfile into the project? Is that worth it? Probably not, some stuff should stay in an onbuild, but worth testing.
• Can/should we use specific
• Should/could we use run-parts for entrypoint.d
  • We should avoid pg_isready to avoid "double ready" problems
• Use envsubst for config file generation from env vars to more easily add more support
• Can/should we git-aggregate and addons linking outside of container?
  • This would allow us to use https://github.com/acsone/git-autoshare more easily
• Can/should we use uv instead of pip for speed?
• Can/should we bring the layout/structure closer to a "standard" Odoo container
• Would a devcontainer be useful?
• Is there any benefit for us using jemalloc?
• Supporting OCA/queue job runner cli? What does that mean/look like?