tito
tito copied to clipboard
rpm-software-management
Add Docker Builder and Releaser
I'd like this as well. Talked with @dgood about getting together to discuss a plan. I saw you mention a hack day. That would be great too.
Yeah I was poking around this yesterday, I'd like to be able to tito build and tito release on projects that just had a Docker file in the project root. Back of my mind I'd also like to stop doing commits on tags.
This quickly got into issues like how do we know what this project (or sub project in the repo) name is, and what the current/last version was.
For project name I was thinking we could assume it from the directory name, use an explicit setting in per-project tito.props, or perhaps introduce a bigger unified yaml config capable of representing all our current config files. i.e. .tito/tito.yaml contains list of sub-projects, their name, what directory they live in, and what builder/releaser to use.
For the version, I'm starting to think we could just search tags for "packagename-somethingthatlookslikeaversion", and assume that was the previous tag, and bump it.
Another idea would be to require the Dockerfile include labels similar to those being used on Fedora. tito could read/update those labels as it does it's thing.
I'm not sure that Dockerfile == rpm.spec file makes sense as a data model for tito.
If tito uses docker-compose as its underlying engine, then tito can focus on parsing the docker-compose.yaml file to bump VERSION args and so forth. docker-compose has grown to support many build patterns and dockerfile features, such as build args, project name vs dir name, and so forth.
If, on the other hand, tito uses dockerfile as the model, then tito is forced to either re-implement much of docker-compose or else restrict itself to a tiny subset of valid docker build patterns.
Interesting, I always viewed Docker compose as more of a tool for deploying applications, rather than building artifacts. I can see the line is getting blurry since I last looked at the project. It would be hard for us to make sense of this in Red Hat as we don't use docker compose, but we do a lot of building Dockerfiles.
I see tito as a tool for artifacts, so getting from Dockerfile + source to a tagged image and maybe pushed to a registry. Haven't started into it but I envision this just as a docker build + tag + push.
What aspects of compose do you worry might need reimplementing in tito?