feat: build different flavors from a single branch

[florentx]

Since the core image layout (5.x version) is softly deprecated, there's interest to keep a single branch to maintain all different flavors.

This is purpose of this refactoring.

Once reviewed, this will become the new main branch and the previous master will be renamed rel-5.X_inactive to keep an archive for future reference.

To try images built from this PR, use these sources in your project's Dockerfile:

FROM ghcr.io/camptocamp/docker-odoo-project:19.0-dev-latest

or, for core flavor:

FROM ghcr.io/camptocamp/odoo-enterprise:19.0-devel-latest
# built from ghcr.io/camptocamp/docker-odoo-project:19.0-core-dev-latest

[ivantodorovich]

Seems good

[florentx]

I've reverted the GH action change (docker/build-push-action <-- docker/bake-action), to reduce the Diff.

Switching to Bake docker buildx bake is not required, and GH runners are already parallelized.

[florentx]

Do we take the opportunity of this convergence to set main as default branch, instead of master ?

This is the proposal:

• main as default branch, is the convergence of 4.x and 5.x images (this PR)
• release-4.5.X is moved to rel-4.5.X_inactive
• master is moved to rel-5.X_inactive

What do you think?
@gurneyalex @ivantodorovich

---

Regarding versioning, this is the proposal:

• to stick with the 3 numbers format <major>.<minor>.<patch> (instead of 5.x.x.x.x)
• to bump both flavors to version 5.4.0 once the merge is completed
• to reserve version 6.0.0 when we remove gosu and stop running the image as root for the main flavor

[ivantodorovich]

I've reverted the GH action change (docker/build-push-action <-- docker/bake-action), to reduce the Diff.

Switching to Bake docker buildx bake is not required, and GH runners are already parallelized.

The benefit of docker bake would be to replace the Makefile and the explicit GH actions matrix with a docker-bake.hcl
See for example: https://github.com/docker/bake-action/tree/master/subaction/matrix

Then the gh actions matrix is generated dynamically from the setup you have in docker-bake, and you can use the exact same docker-bake definition when building locally without any extra steps.

But I agree it would make too much diff. I can take a look into this at some point in the future

[florentx]

• new branch main is set as default
• branches are merged
• this PR can be closed
• draft PR for Bake action (to take over) : (experiment) feat: use Bake GH action #440
• and some additional clean-up / refactoring to review