Doodba

Doodba stands for Docker Odoo Base, and it is a highly opinionated image ready to put Odoo inside it, but without Odoo.

What?

Yes, the purpose of this is to serve as a base for you to build your own Odoo project, because most of them end up requiring a big amount of custom patches, merges, repositories, etc. With this image, you have a collection of good practices and tools to enable your team to have a standard Odoo project structure.

BTW, we use Debian. I hope you like that.

Why?

Because developing Odoo is hard. You need lots of customizations, dependencies, and if you want to move from one version to another, it's a pain.

Also because nobody wants Odoo as it comes from upstream, you most likely will need to add custom patches and addons, at least, so we need a way to put all together and make it work anywhere quickly.

How?

You can start working with this straight away with our [template][].

<!-- prettier-ignore-start --> <!-- prettier-ignore --> <!-- toc -->

• Image usage
  • /opt/odoo/custom: The important one
    • /opt/odoo/custom/entrypoint.d
    • /opt/odoo/custom/build.d
    • /opt/odoo/custom/conf.d
    • /opt/odoo/custom/ssh
    • /opt/odoo/custom/src
      • /opt/odoo/custom/src/odoo
      • /opt/odoo/custom/src/private
      • /opt/odoo/custom/src/repos.yaml
        • Automatic download of repos
      • /opt/odoo/custom/src/addons.yaml
      • /opt/odoo/custom/dependencies/*.txt
  • /opt/odoo/common: The useful one
  • /opt/odoo/auto: The automatic one
    • /opt/odoo/auto/addons
    • /opt/odoo/auto/odoo.conf
• The Dockerfile
• Bundled tools
  • addons
  • click-odoo and related scripts
  • nano
  • log
  • pot
  • psql
  • inotify
  • debugpy
  • pudb
  • git-aggregator
  • autoaggregate
    • Example repos.yaml file
  • odoo
• Subproject template
• FAQ
  • Will there be not retrocompatible changes on the image?
  • This project is too opinionated, but can I question any of those opinions?
  • What's this hooks folder here?
  • How can I pin an image version?
  • How can I help?
• Related Projects

<!-- tocstop --> <!-- prettier-ignore-end -->

Image usage

Basically, every directory you have to worry about is found inside /opt/odoo. This is its structure:

custom/
    entrypoint.d/
    build.d/
    conf.d/
    ssh/
        config
        known_hosts
        id_rsa
        id_rsa.pub
    dependencies/
        apt_build.txt
        apt.txt
        gem.txt
        npm.txt
        pip.txt
    src/
        private/
        odoo/
        addons.yaml
        repos.yaml
common/
    entrypoint.sh
    build.sh
    entrypoint.d/
    build.d/
    conf.d/
auto
    addons/
    odoo.conf

Let's go one by one.

/opt/odoo/custom: The important one

Here you will put everything related to your project.

/opt/odoo/custom/entrypoint.d

Any executables found here will be run when you launch your container, before running the command you ask.

/opt/odoo/custom/build.d

Executables here will be aggregated with those in /opt/odoo/common/build.d.

The resulting set of executables will then be sorted alphabetically (ascending) and then subsequently run.

/opt/odoo/custom/conf.d

Files here will be environment-variable-expanded and concatenated in /opt/odoo/auto/odoo.conf in the entrypoint.

You can use a different custom directory to concatenate the configuration by using the CUSTOM_CONF_DIR environment variable in the odoo service of the compose specific file.

/opt/odoo/custom/ssh

It must follow the same structure as a standard ~/.ssh directory, including config and known_hosts files. In fact, it is completely equivalent to ~root/.ssh.

The config file can contain IdentityFile keys to represent the private key that should be used for that host. Unless specified otherwise, this defaults to identity[.pub], id_rsa[.pub] or id_dsa[.pub] files found in this same directory.

This is very useful to use deployment keys that grant git access to your private repositories.

Example - a private key file in the ssh folder named my_private_key for the host repo.example.com would have a config entry similar to the below:

Host repo.example.com
  IdentityFile ~/.ssh/my_private_key

Or you could just drop the key in id_rsa and id_rsa.pub files and it should work by default without the need of adding a config file.

Host key checking is enabled by default, which means that you also need to provide a known_hosts file for any repos that you wish to access via SSH.

In order to disable host key checks for a repo, your config would look something like this:

Host repo.example.com
  StrictHostKeyChecking no

For additional information regarding this directory, take a look at this [Digital Ocean Article][ssh-conf].

/opt/odoo/custom/src

Here you will put the actual source code for your project.

When putting code here, you can either:

• Use [repos.yaml][], that will fill anything at build time.
• Directly copy all there.

Recommendation: use [repos.yaml][] for everything except for [private][], and ignore in your .gitignore and .dockerignore files every folder here except [private][], with rules like these:

odoo/custom/src/*
!odoo/custom/src/private
!odoo/custom/src/*.*

/opt/odoo/custom/src/odoo

REQUIRED. The source code for your odoo project.

You can choose your Odoo version, and even merge PRs from many of them using [repos.yaml][]. Some versions you might consider:

• [Original Odoo][], by [Odoo S.A.][].

• [OCB][] (Odoo Community Backports), by [OCA][]. The original + some features - some stability strictness.

• [OpenUpgrade][], by [OCA][]. The original, frozen at new version launch time + migration scripts.

/opt/odoo/custom/src/private

REQUIRED. Folder with private addons for the project.

/opt/odoo/custom/src/repos.yaml

A git-aggregator configuration file.

It should look similar to this:

# Odoo must be in the `odoo` folder for Doodba to work
odoo:
  defaults:
    # This will use git shallow clones.
    # $DEPTH_DEFAULT is 1 in test and prod, but 100 in devel.
    # $DEPTH_MERGE is always 100.
    # You can use any integer value, OTOH.
    depth: $DEPTH_MERGE
  remotes:
    origin: https://github.com/OCA/OCB.git
    odoo: https://github.com/odoo/odoo.git
    openupgrade: https://github.com/OCA/OpenUpgrade.git
  # $ODOO_VERSION is... the Odoo version! "11.0" or similar
  target: origin $ODOO_VERSION
  merges:
    - origin $ODOO_VERSION
    - odoo refs/pull/25594/head # Expose `Field` from search_filters.js

web:
  defaults:
    depth: $DEPTH_MERGE
  remotes:
    origin: https://github.com/OCA/web.git
    tecnativa: https://github.com/Tecnativa/partner-contact.git
  target: origin $ODOO_VERSION
  merges:
    - origin $ODOO_VERSION
    - origin refs/pull/1007/head # web_responsive search
    - tecnativa 11.0-some_addon-custom # Branch for this customer only

Automatic download of repos

Doodba is smart enough to download automatically git repositories even if they are missing in repos.yaml. It will happen if it is used in [addons.yaml][], except for the special [private][] repo. This will help you keep your deployment definitions DRY.

You can configure this behavior with these environment variables (default values shown):

• DEFAULT_REPO_PATTERN="https://github.com/OCA/{}.git"
• DEFAULT_REPO_PATTERN_ODOO="https://github.com/OCA/OCB.git"

As you probably guessed, we use something like str.format(repo_basename) on top of those variables to compute the default remote origin. If, i.e., you want to use your own repositories as default remotes, just add these build arguments to your docker-compose.yaml file:

# [...]
services:
  odoo:
    build:
      args:
        DEFAULT_REPO_PATTERN: &origin "https://github.com/Tecnativa/{}.git"
        DEFAULT_REPO_PATTERN_ODOO: *o