Answers: <p>If you think of the Dockerfile as a kind of "<em><a href="https://en.wikipedia.org/wiki/Bill_of_materials" rel="nofollow noreferrer">bill of materials</a></em>" for your containers, then there is the following consideration:</p>
  
  <ul>
  <li>container environments are mostly same - you can use many Dockerfiles in same folder, or even just one Dockerfile with parametrized builds</li>
  <li>container environments are or might divert in terms of further "local assembly parts" configuration files, scripts etc., then you are better off with using separate folders.</li>
  </ul>
  
  <p>Branching has rather to do with developing <em>versions</em>, or also independent features which then should be anyway merged together. See <a href="https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow" rel="nofollow noreferrer">Git flow</a> on this topic.</p>
  
  <p>As a reference project laoyut, check for example the <a href="https://github.com/docker-library/tomcat/tree/37baee2462247279efcf9e072f55d4ff3086a7a9/7" rel="nofollow noreferrer">GitHub project</a> linked from <a href="https://hub.docker.com/_/tomcat/" rel="nofollow noreferrer">Tomcat Docker Hub</a> site. Here you find different folders, even with single Dockerfiles.</p>
  
  <p>See also this TeX-Docker distro:</p>
  
  <ul>
  <li><a href="https://hub.docker.com/r/raabf/texstudio-versions/" rel="nofollow noreferrer">https://hub.docker.com/r/raabf/texstudio-versions/</a></li>
  </ul>
  
  <p>Side note: strange enough there is no "official" Docker distro for TeX, while many other well established open source communities have this <em><a href="https://hub.docker.com/u/library/" rel="nofollow noreferrer">library</a></em> entry.</p>
  
Answers: CC BY-SA 4.0
Answers: 2018-11-28T11:07:36.260Z
Answers: One thing that I don't understand is how I could use many Docker files in the same directory with automated builds. I know that when I build them manually or through a makefile I could set the docker file name for each tagged image, but I don't know how to do it with automated builds.
Answers: gvgramazio
Answers: CC BY-SA 4.0
Answers: 2018-11-28T11:10:36.207Z
Answers: Do you mean the Docker Hub image build automation?
Answers: Ta Mu
Answers: CC BY-SA 4.0
Answers: 2018-11-28T11:12:40.380Z
Answers: I currently use gitflow on other projects. I wanted to use it also in this case but first I should solve the part about automated builds of semantic version tags with regex (that will be the topic of my next question on devops probably). Also, even if it is true that in gitflow version are developed through branch, the opposite could be not true, e.g. I could use branches for features. Also, each release branch is supposed to die somewhere while the tags that indicate the version is supposed to survive and not to be moved.
Answers: gvgramazio
Answers: CC BY-SA 4.0
Answers: 2018-11-28T11:15:43.303Z
Answers: Yes, I mean exactly that. I edited my question to better clarify which is the context in which I want to develop these things. However, think of the edit only has a clarification of the context, my question still is about the best practices to put on a docker hub project. I will post the other doubts in other question. This is because if the question is too strict maybe it could not be helpful for future users.
Answers: gvgramazio
Answers: CC BY-SA 4.0
Answers: 2018-11-28T12:33:51.130Z
Answers: added more references, maybe an example can be the official Tomcat Docker Hub site.
Answers: Ta Mu
Answers: CC BY-SA 4.0
Answers: 2018-11-28T22:40:01.240Z
Answers: I really appreciate your effort. In particular, the TeX-docker repository is the first automated build with multiple tags that I've seen. I will explore it in details. However, I miss how he/she automates the process but probably I will soon send a mail. I think that it's related to webhooks (a concept that I still don't grasp).
Answers: gvgramazio
Answers: CC BY-SA 4.0
Answers: 2018-11-28T09:16:16.653Z
Answers: 2018-11-28T12:30:04.080Z
Answers: 2018-11-28T12:30:04.080Z
Answers: Ta Mu
Body: <p>I've seen a lot of repositories with Docker images and I think (correct me if my guessing is wrong) that the projects that handle a docker image with multiple tags can be grouped into three groups: </p>
  
  <ul>
  <li>Dockerfiles with different names in the same directory.</li>
  <li>Dockerfiles with the same name (i.e. "Dockerfile") in different directories.</li>
  <li>Dockerfiles with the same name (i.e. "Dockerfile") in different branches.</li>
  </ul>
  
  <p>I've looked at the Docker documentation page but there are no suggestions on how one should manage multiple tag images. I'm not looking for a subjective answer. Of course, any advice will be appreciated but what I want is to know the pros and cons of each of the three possibilities.</p>
  
  <p>Of course, there is the possibility that I've understood nothing of how docker images should be deployed. In this unfortunate case, please be merciful and point me in the right direction.</p>
  
  <hr>
  
  <h3>Case study</h3>
  
  <p>I wanted to pose a general question but I realized that maybe it was too broad. For this reason, I explain here what is my case hoping that could help a bit more what I wanted to achieve and what I've done now (this question is about only a part of what I wanted to achieve). </p>
  
  <p>What I want is to develop a docker hub automated build linked to a Git Hub repository. The images are about LaTeX on Ubuntu. The first build, tagged <code>base</code>, starts from Ubuntu 18.04 and comes with <code>texlive-base</code>. Another build, tagged <code>full</code>, starts from the build tagged <code>base</code> and comes with <code>texlive-full</code>. Another two builds, tagged <code>develop-base</code> and <code>develop-full</code>, will start from the respectively builds without 'develop' and will come with writing and visualization tools. All the builds will probably have some semantic versioning system. </p>
  
  <p>What I've done right now is implement <code>base</code> and <code>full</code> through two different Docker files into two different directories in the same Git Hub repository. Whenever a tag <code>base</code> or <code>full</code> is created/moved, the corresponding build is triggered. This implementation has a problem: if I move the tag <code>base</code>, the image <code>base</code> is correctly built but all the images that depend on it are not built again and I have to manually trigger them. What I've thought is to have a branch for each tagged image (with the corresponding automated builds triggered at each new push on that branch) and a tag system to keep track of the version number (with the corresponding automated builds triggered at each new tag). The tags will be <code>base</code>, <code>full</code>, <code>develop-base</code>, etc. for each latest version and with semantic versioning for each version, including the latest, i.e. <code>1.0-base</code>, <code>2.3-full</code>, <code>1.3.1-develop-base</code>, ecc. In the latter case, the automated build triggering will probably have to handle regular expression to automatically label the images with a version number.</p>
  
  <p>I realize that my question isn't very related to what I wanted to achieve but I want to learn to walk before trying to run. Thus, I want to understand when and why one should choose one way or the other to put on a docker hub repository with several images and which are those ways. The project of LaTeX images itself, that maybe you could think that is very naive, is to deeply understand the way docker, docker hub, docker cloud, docker compose, ecc. work.</p>
  
Comments: CC BY-SA 4.0
Comments: 2018-11-27T07:31:21.163Z
Comments: I would hazard that this question has no good canonical answer. It is worth describing patterns though. The right pattern would depend on your codebase, dependencies and delivery pipelines. Would you consider rewording the question to ask about patterns instead of the single best way?
Comments: Bruce Becker
Comments: CC BY-SA 4.0
Comments: 2018-11-27T10:11:07.933Z
Comments: @BruceBecker In my last sentence, I said that probably I've missed the whole point. My aim is to understand how to organize a project that is supposed to have multiple tag images. If you think that the question could be rewording to better achieve this result, feel free to edit it. I'm not lazy, simply I don't know what should I ask instead of what I already did.
Comments: gvgramazio
Comments: CC BY-SA 4.0
Comments: 2018-11-27T10:13:27.893Z
Comments: @BruceBecker I don't know if it is relevant but I want that my repository should be linked to an automatic build. I didn't specify it in the question because I was worried to mix too much things that are not completely clear in my mind.
Comments: gvgramazio
Comments: CC BY-SA 4.0
Comments: 2018-11-27T11:39:08.173Z
Comments: I agree with @BruceBecker that here it seems hard to provide a "canonical" answer. I would even suggest there is no direct connection between tagging of images and the location of Dockerfiles.
  That is, you could have just one Dockerfile but many tags if you give them by date and number of the CI build which produced them.
  Also, you could parametrize a Dockerfile including the base image to use which might reduce the demand to have many Dockerfiles.
Comments: Ta Mu
Comments: CC BY-SA 4.0
Comments: 2018-11-27T11:41:40.740Z
Comments: @gvgramazio - no stress, I was just trying to get at the heart of your question, so that we can have a useful answer _and_ actually solve your problem :) I think your comments help to clarify the situation, so an answer should be possible soon.
Comments: Bruce Becker
Comments: CC BY-SA 4.0
Comments: 2018-11-27T14:08:27.797Z
Comments: @Peter I don't think that I have understood your comment. The problem is that I've not used yet many of the features you've mentioned. Are you saying that I can use only one dockerfile to produce multiple docker images? Just to point out which my case is: I've couple of dockerfiles where each one is almost a enanched version of the previous one (i.e. all of them but one started from a docker image defined by a docker file in the same repository).
Comments: gvgramazio
Comments: CC BY-SA 4.0
Comments: 2018-11-27T14:11:32.277Z
Comments: @BruceBecker. Don't worry, I'm glad that you want to help me. Right now I'm able to do what I need. However, I want to do it in the proper way. Unfortunately, I don't know which is the proper way. :)
Comments: gvgramazio
Comments: CC BY-SA 4.0
Comments: 2018-11-27T15:00:32.993Z
Comments: Yes sure it depends but you can  use variable, see ARG
Comments: Ta Mu
Comments: CC BY-SA 4.0
Comments: 2018-11-27T15:18:01.120Z
Comments: @Peter. Now I think to have understood what you mean but I don't think that this is my case. See [my repo](https://github.com/gvgramazio/docker-texlive), the image tagged 'full' is based on the image tagged 'base'. In this case, I should put a different ARG basically for each RUN command. I don't see the point of doing so. Maybe I miss it or maybe my case is not suitable for this solution.
Comments: gvgramazio
Comments: CC BY-SA 4.0
Comments: 2018-11-27T15:21:15.700Z
Comments: I configured an automated build on docker hub for that repo (and my aim is to continue to use automated builds but to actually use them at their best). It compiles a new image tagged `base` from the dockerfile in the `base` directory whenever I tag a commit with `base`. A similar thing is done with `full` tag.
Comments: gvgramazio
Comments: CC BY-SA 4.0
Comments: 2018-11-28T09:09:17.210Z
Comments: well if really the only difference will be this "base/full" keyword you could indeed pass an ARG parameter and use it in RUN to evaluate which flavour you need. Otherwise, if these two TEX flavours installations should drift more apart, I do not see a problem of having two folders. Two folders are actually better in case you'd have some side scripts which are also different.
Comments: Ta Mu
Tags: <docker><dockerfile><learning>
Title: What is the best way to put on a repository for a docker image with multiple tags?
UserDisplayName: gvgramazio
ThreadText: # What is the best way to put on a repository for a docker image with multiple tags?
  
  (Asked by: username_0 on 2018-11-26)
  
  I've seen a lot of repositories with Docker images and I think (correct me if my guessing is wrong) that the projects that handle a docker image with multiple tags can be grouped into three groups:
  
  * Dockerfiles with different names in the same directory.
  * Dockerfiles with the same name (i.e. "Dockerfile") in different directories.
  * Dockerfiles with the same name (i.e. "Dockerfile") in different branches.
  
  I've looked at the Docker documentation page but there are no suggestions on how one should manage multiple tag images. I'm not looking for a subjective answer. Of course, any advice will be appreciated but what I want is to know the pros and cons of each of the three possibilities.
  
  Of course, there is the possibility that I've understood nothing of how docker images should be deployed. In this unfortunate case, please be merciful and point me in the right direction.
  
  ---
  
  ### Case study
  
  I wanted to pose a general question but I realized that maybe it was too broad. For this reason, I explain here what is my case hoping that could help a bit more what I wanted to achieve and what I've done now (this question is about only a part of what I wanted to achieve).
  
  What I want is to develop a docker hub automated build linked to a Git Hub repository. The images are about LaTeX on Ubuntu. The first build, tagged `base`, starts from Ubuntu 18.04 and comes with `texlive-base`. Another build, tagged `full`, starts from the build tagged `base` and comes with `texlive-full`. Another two builds, tagged `develop-base` and `develop-full`, will start from the respectively builds without 'develop' and will come with writing and visualization tools. All the builds will probably have some semantic versioning system.
  
  What I've done right now is implement `base` and `full` through two different Docker files into two different directories in the same Git Hub repository. Whenever a tag `base` or `full` is created/moved, the corresponding build is triggered. This implementation has a problem: if I move the tag `base`, the image `base` is correctly built but all the images that depend on it are not built again and I have to manually trigger them. What I've thought is to have a branch for each tagged image (with the corresponding automated builds triggered at each new push on that branch) and a tag system to keep track of the version number (with the corresponding automated builds triggered at each new tag). The tags will be `base`, `full`, `develop-base`, etc. for each latest version and with semantic versioning for each version, including the latest, i.e. `1.0-base`, `2.3-full`, `1.3.1-develop-base`, ecc. In the latter case, the automated build triggering will probably have to handle regular expression to automatically label the images with a version number.
  
  I realize that my question isn't very related to what I wanted to achieve but I want to learn to walk before trying to run. Thus, I want to understand when and why one should choose one way or the other to put on a docker hub repository with several images and which are those ways. The project of LaTeX images itself, that maybe you could think that is very naive, is to deeply understand the way docker, docker hub, docker cloud, docker compose, ecc. work.
  
  **Tags:** docker, dockerfile, learning
  
  > **Comments:**
  > **username_1**: I would hazard that this question has no good canonical answer. It is worth describing patterns though. The right pattern would depend on your codebase, dependencies and delivery pipelines. Would you consider rewording the question to ask about patterns instead of the single best way?  
  > **username_0**: @username_1 In my last sentence, I said that probably I've missed the whole point. My aim is to understand how to organize a project that is supposed to have multiple tag images. If you think that the question could be rewording to better achieve this result, feel free to edit it. I'm not lazy, simply I don't know what should I ask instead of what I already did.  
  > **username_0**: @username_1 I don't know if it is relevant but I want that my repository should be linked to an automatic build. I didn't specify it in the question because I was worried to mix too much things that are not completely clear in my mind.  
  > **username_2**: I agree with @username_1 that here it seems hard to provide a "canonical" answer. I would even suggest there is no direct connection between tagging of images and the location of Dockerfiles. That is, you could have just one Dockerfile but many tags if you give them by date and number of the CI build which produced them. Also, you could parametrize a Dockerfile including the base image to use which might reduce the demand to have many Dockerfiles.  
  > **username_1**: @username_0 - no stress, I was just trying to get at the heart of your question, so that we can have a useful answer _and_ actually solve your problem :) I think your comments help to clarify the situation, so an answer should be possible soon.  
  > **username_0**: @Peter I don't think that I have understood your comment. The problem is that I've not used yet many of the features you've mentioned. Are you saying that I can use only one dockerfile to produce multiple docker images? Just to point out which my case is: I've couple of dockerfiles where each one is almost a enanched version of the previous one (i.e. all of them but one started from a docker image defined by a docker file in the same repository).  
  > **username_0**: @username_1. Don't worry, I'm glad that you want to help me. Right now I'm able to do what I need. However, I want to do it in the proper way. Unfortunately, I don't know which is the proper way. :)  
  > **username_2**: Yes sure it depends but you can  use variable, see ARG  
  > **username_0**: @Peter. Now I think to have understood what you mean but I don't think that this is my case. See [my repo](https://github.com/username_0/docker-texlive), the image tagged 'full' is based on the image tagged 'base'. In this case, I should put a different ARG basically for each RUN command. I don't see the point of doing so. Maybe I miss it or maybe my case is not suitable for this solution.  
  > **username_0**: I configured an automated build on docker hub for that repo (and my aim is to continue to use automated builds but to actually use them at their best). It compiles a new image tagged `base` from the dockerfile in the `base` directory whenever I tag a commit with `base`. A similar thing is done with `full` tag.  
  > **username_2**: well if really the only difference will be this "base/full" keyword you could indeed pass an ARG parameter and use it in RUN to evaluate which flavour you need. Otherwise, if these two TEX flavours installations should drift more apart, I do not see a problem of having two folders. Two folders are actually better in case you'd have some side scripts which are also different.  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_2 on 2018-11-28. Score: 2
  
  If you think of the Dockerfile as a kind of "*[bill of materials](https://en.wikipedia.org/wiki/Bill_of_materials)*" for your containers, then there is the following consideration:
  
  * container environments are mostly same - you can use many Dockerfiles in same folder, or even just one Dockerfile with parametrized builds
  * container environments are or might divert in terms of further "local assembly parts" configuration files, scripts etc., then you are better off with using separate folders.
  
  Branching has rather to do with developing *versions*, or also independent features which then should be anyway merged together. See [Git flow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) on this topic.
  
  As a reference project laoyut, check for example the [GitHub project](https://github.com/docker-library/tomcat/tree/37baee2462247279efcf9e072f55d4ff3086a7a9/7) linked from [Tomcat Docker Hub](https://hub.docker.com/_/tomcat/) site. Here you find different folders, even with single Dockerfiles.
  
  See also this TeX-Docker distro:
  
  * <https://hub.docker.com/r/raabf/texstudio-versions/>
  
  Side note: strange enough there is no "official" Docker distro for TeX, while many other well established open source communities have this *[library](https://hub.docker.com/u/library/)* entry.
  
  > **Comments:**
  > **username_0**: One thing that I don't understand is how I could use many Docker files in the same directory with automated builds. I know that when I build them manually or through a makefile I could set the docker file name for each tagged image, but I don't know how to do it with automated builds.  
  > **username_2**: Do you mean the Docker Hub image build automation?  
  > **username_0**: I currently use gitflow on other projects. I wanted to use it also in this case but first I should solve the part about automated builds of semantic version tags with regex (that will be the topic of my next question on devops probably). Also, even if it is true that in gitflow version are developed through branch, the opposite could be not true, e.g. I could use branches for features. Also, each release branch is supposed to die somewhere while the tags that indicate the version is supposed to survive and not to be moved.  
  > **username_0**: Yes, I mean exactly that. I edited my question to better clarify which is the context in which I want to develop these things. However, think of the edit only has a clarification of the context, my question still is about the best practices to put on a docker hub project. I will post the other doubts in other question. This is because if the question is too strict maybe it could not be helpful for future users.  
  > **username_2**: added more references, maybe an example can be the official Tomcat Docker Hub site.  
  > **username_0**: I really appreciate your effort. In particular, the TeX-docker repository is the first automated build with multiple tags that I've seen. I will explore it in details. However, I miss how he/she automates the process but probably I will soon send a mail. I think that it's related to webhooks (a concept that I still don't grasp).  
  
  ---
  
  