Allow a single-commit update mechanism for the scaffolding

[yajo]

I think the best solution would be moving the scaffolding to its own repo and basing it on cookiecutter once https://github.com/audreyr/cookiecutter/issues/784 gets fixed.

[joserprieto]

Hi, @Yajo

Well, this thread is some interesting; i was thinking a lot of on it, because I need a simple dev / deploy all-in-one system for Odoo (Docker based).

As we have the Docker Odoo Image of Tecnativa, we have a very customizable Odoo Image, with a lot of good features.

But, i think that the image has to be focused only in give the Odoo Image, not more; so, the docker-compose files with the smtp-fake/smtp-real, inbox-fake, wdb, traefik, etc., may be features that isn't attached to the Odoo Base Image and/or in the repo; has to be samples of the stack that you can use for Odoo.

For example; i want to use nginx as inverse proxy; or, i want to use my external smtp server; or... There are a lot of stack configurations to get a production ready stack for Odoo, and.. What is better? I think that only are differents options, may be one is better for one case, and another, for other case....

So, i go to make a proposal; one of the simpliest way (for me) to have the Odoo Base Image on the same repository of your dev, and have the dev/prod on the same place (the differencies will be the .env files, and .yml files for docker-compose / stack definitiion), wil be:

1. Have the Tecnativa/docker-odoo-base/tree/scaffolding as a git submodule
2. The files to define the Odoo configuration of the Base Image, will be on the root of project; and this files, will be: addons.yaml, repos.yaml, apt.txt, apt_build.txt, gem.txt, npm.txt, and pip.txt; the ssh config and keys, will be on the root directory too.
3. The docker-compose.yml, etc., has to be on the root of the project.
4. One directory, for example, ./src, will have the custom modules of your project.
5. The project, build at this form, can has two branches, one for production, and one por dev, with the different configuration files.

A possible directory structure can be the next:

.
├── docker-odoo-base <-- submodule with the repo of Tecnativa/docker-odoo-base/tree/scafolding
│   
├── etc
│     └──docker-odoo-base
│        ├── dependencies
│        │   ├── apt.txt
│        │   ├── apt_build.txt
│        │   ├── gem.txt
│        │   ├── npm.txt
│        │   └── pip.txt
│        ├── git-aggregator
│        │   ├── addons.yaml
│        │   └── repositories.yaml
│        └── .. other
│
├── src
│   └── (your custom source code)
│
├── .env <-- at .gitignored, not versioned
├── .env.sample
├── dev.sample.yml
├── docker-compose.sample.yml
├── docker-compose.yml  <-- at .gitignored, not versioned
├── prod..sample.yml
└── prod.stack-nginx.sample.yml

Another interesting approach, but these be more complicated to implement, is to have the src of odoo and repos on the Odoo Base Image; why? for deploy the image directly, and avoid the build phase on production.

If you like the approach of have a submodule, and the directory structure that i show abobe, i can make a PoC, if you want.

Regards.

[pedrobaeza]

@Yajo is going to be on holidays a week, so he is not going to be able to answer soon.

[joserprieto]

Ok, grax, @pedrobaeza :)

[yajo]

Hi there @joserprieto, I think we are mixing issues here.

This issue's target is to reduce subprojects' amount of commits while still being able to update to latest scaffolding.

Your suggestion means dramatically changing the scaffolding's structure to make it less opinionated, and to better match other mental models on how should the subproject be structured, but that's exactly the opposite to this project's approach, which is supposed to be opinionated. Without opinions, you force users to study all alternatives and pick one, but this project's goal is to make it simple and let you have a production-ready customized odoo PaaS in a matter of minutes. You need opinions for that. But nobody forces you to follow ours if you already have yours and know how to apply them. 😊

Of course you are free to use the base image while not using the scaffolding, and you have builtin methods to change a little bit the image-scaffolding relation, mainly this variable: https://github.com/Tecnativa/docker-odoo-base/blob/6cc9cb892ca03c5ae95c790171af5b05d3117bec/11.0.Dockerfile#L40

But not, we are not interested in supporting nginx above traefik unless there's a reason for it, and in such case we would drop traefik (you get the point). The scaffolding is just a template, just use yours if you prefer, it's not a problem if it's not the "official" one. There's a test for a "smallest" possible scaffolding that would work with this image. Check it out if you don't like our scaffolding. 😉

That being said, the scaffolding's gonna change (#20, #98) but we're still working on that. If you have further proposals on things to change, or even opinions to change, please open separate issues for them, we are open to suggestions. ☺️

[joserprieto]

Oh, sorry; i thought that you want a "simply" method to develop and deploy to production, in one single repo; when the develop phase ended, you will deploy with the same repo (git clone / git commit / git pull / git push, you know); and changing confs with the different YAML compose files, you can have dev environment, prod enviroment, and so on.

Well, i get your point of view, and you developed this approach, so, this is your developing; i can, only, suggest you other approachs that i think that can be usefuls; and, also, give you many thanks for a lot of work to make a valid approach like this.

[yajo]

Moved to https://github.com/Tecnativa/doodba-scaffolding/issues/2, continue discussion there.