-
Notifications
You must be signed in to change notification settings - Fork 6
Conex support for multiple images in the same repo #121
Comments
Would there be a convention about Dockerfile locations within a repository, or would conex parse a docker-compose file? |
I don't think any parsing or conventions would be necessary: the docker-compose file defines where each image's context/Dockerfile lives and outputs all of those images in the format |
Oh I see -- so you're imagining that conex will run Once they're built, how would it know what it needs to retag & upload? If the image is |
It's the folder that the docker-compose file is in, which is nice because it leaves the actual Dockerfile locations up to the developer. Currently I'm doing something like...
And if I rename the folder...
|
This is a great idea that would be beneficial for project scalability and supporting different environments. Any movement on this? |
Conex currently only builds one container per repo.
We have a repo, we'll call it
tabby-cat
, which defines multiple containers and usesdocker-compose
as well as custom bash scripts to build and push the multiple images to ECR. The multiple images are tagged with:where each of those sub-images is defined in a different part of the
services
section of thedocker-compose.yml
file.It would be great if we could rewrite conex to support multiple containers.
Plan for how to do this
The outputs of
docker-compose build
are multiple images with the formattabby-cat_rails
,tabby-cat_cgimap
, etc., wheretabby-cat
is the name of the folder andrails
is the name of the section of the docker compose file. Using some string transformations, I think we could re-tag these images with the<repo>:<gitsha>-<subimage>
format and push all of them to ECR.cc/ @Yuffster @rclark
The text was updated successfully, but these errors were encountered: