Closed blaggacao closed 4 years ago
Of special interest would be the repository scaffolding process which is currently implemented in bash
docky init odoo
for example.
Please also note the COMPOSE_IMPERSONATION='$(id -u):$(id -g)'
technique to enable propper UID:GID while scaffolding out of the docker image itself.
I guess that compose impersonation is the key to bundling module templating within a devops
container. Therefore, it can be implemented rather app agnostic (odoo, rails, etc)
Furthermore, I would suggest not to include everything within the docky API but load off some aspects, or example in the odoo realm to a :devops
container Why? -> We also need an API out of the local command line and that's where a container is the better choice (as deployable artifact).
That means that docky migrate
should interact with an app specific :devops
image rather than some local scoped commands.
Do I make myself understand?
Thanks for you comments, docky did change a lot since your comments. Now it's more tiny and closer to docker-compose than it was at the time.
I like most of the design choices done by docky and I'd be wondering how we could combine the CLI ease of docky with the slightly stronger design choices provided by dockery-odoo-scaffold.
Anyone willing to help me in that process?