Ability to add extra tag builds

[dlip]

When there is a container A that container B depends on, in B's Dockerfile I reference it with the command FROM myname/A. Unfortunately fig only tags with docker_A, but I don't want to use that in my Dockerfile. Something like the following would be good

A:
  build: A
  tags:
    - myname/A
B:
  image: myname/A

[marksteve]

👍 I could work on this

[prologic]

+1 I need this as well. I'm in a situation where I need to build image A that image B depends on in the FROM line but would like to explicitly name it in the same way as per above.

Has anyone got this working yet? Otherwise I may also hack this up and submit a PR :)

[dnephin]

+1, I would use this

[aanand]

What's wrong with just setting build: A in both services? The cache will ensure that work isn't repeated - the same image will get tagged with projectname_A and projectname_B.

[dnephin]

I can't speak for others, but for my use case the images built by fig will be pushed into a registry (after the local fig workflow is done) and re-used by other services.

The default names are great locally, but not great for pushing around (and they're missing the user prefix). It's totally possible to do this outside of fig, but it would be nice to have.

[prologic]

Same here.

James Mills / prologic

E: prologic@shortcircuit.net.au
W: prologic.shortcircuit.net.au

On Tue, Aug 26, 2014 at 6:55 AM, Daniel Nephin notifications@github.com
wrote:

I can't speak for others, but for my use case the images built by fig will
be pushed into a registry (after the local fig workflow is done) and
re-used by other services.

The default names are great locally, but not great for pushing around (and
they're missing the user prefix). It's totally possible to do this outside
of fig, but it would be nice to have.

—
Reply to this email directly or view it on GitHub
#213 (comment).

[koliyo]

+1, allow custom tags please!

[mahnunchik]

+1

[michaeljs1990]

+1 this is killer that it's not in yet. Hurts more that someone already made a PR to do this and it was closed.

[dnephin]

1.6.0 RC1 was just released which includes #2092. You can now include image and build and build will use the image name in image.

[nanoz]

How would you add extra tags to a build without an extra command @dnephin ?

I wish there was a tag option to the build instruction allowing me to do something like this

build:
  tag:
    - org/image:tag1
    - org/image:tag2
    - org/image:tag3

All of my build context would then be explicitly declared in docker-compose.yml, allowing me to consistently run a docker-compose build in all my projects.

[dnephin]

You can't add extra tags, but you can tag the build with a single tag by using image.

Compose is not primarily designed for building images. The primary focus is running containers. So while Compose does provide some basic support for building an image, it's not necessarily going to be able to support many build-tag-push workflows.

You might be interested in dobi (a tool I've been prototyping). It's designed specifically for these types of workflow tasks. There's an example for building and tagging images.

[CWSpear]

Compose isn't primarily built for building, nor pushing... but it does.

You can build with docker-compose build (which also tags) and you can push with docker-compose build to matching tags via your the services.[service].image name.

The workflow is pretty common and it would be very useful from a user-experience to be able to use multiple tags, i.e. so you can do stuff like my-image, my-image:2, my-image:2.1 and image:2.1.14 all as the same image. Then, when you release image:2.1.15, you just need to docker-compose build and docker-compose push and it will update all your tags; leaving the 2.1.14 as that specific old version, etc.

[dkarlovi]

What would be really useful is supporting an environment variable (say, COMPOSE_BUILD_TAG), this way you could run your build with your current Git branch name, say:

services:
    app:
         image: app:latest
    web:
         image: web:latest

If you run:

COMPOSE_BUILD_TAG=production docker-compose build

which would produce

• app:latest
• app:production
• web:latest
• web:production

[VolCh]

@dkarlovi you can tag dynamically now with

        image: app:${COMPOSE_BUILD_TAG}

but only one tag at build time. There is no way to multiply tag now. It will be possible with minor coding if docker-compose translates COMPOSE_BUILD_TAG like a tag list for example comma separated.

[synergiator]

I support this use case because in our project we always need two tags, "latest" and date-tagged.

[dirkschneemann]

Since I was annoyed as well of not being able to define multiple tags in my docker-compose.yml file, I started collecting some possible work-arounds. You might want to check this answer on StackOverflow.

[kilianc]

I would love this, it would make so many things much easier. Handling cache_from with dynamic tags is very cumbersome I wish I had a :latest + the image version all in one shot so that the cache always points to latest.

[jakubigla]

Compose isn't primarily built for building, nor pushing... but it does.

But it should be the recommended way of building docker images as it's the only declarative way of defining all build options, that works really well with .env file.

I also don't like any of the suggested solutions for that (as their mess with with the yaml file).

I believe we should have something like this:
docker-compose tag <tag_name>
This would behave in a similar way as docker-compose build - it only tags those images, which in docker-compose.yml have build option:

services:
    app:
        image: some-image-name:some-tag
        build:
            context: .

[MohammedNoureldin]

After 3 years, any news?

[shin-]

It's been answered already. The feature as requested is just out of scope of what Compose is designed to do, and we will not be looking to implement it beyond what already exists.

Thank you for your understanding.