docker:push goal pushing old docker images to private registry

[KowKiller]

Hi,

I build and push an image to my private registry with the command:
mvn clean docker:build docker:push
And this is how I configured the docker maven plugin:

                <plugin>
                    <groupId>io.fabric8</groupId>
                    <artifactId>docker-maven-plugin</artifactId>
                    <version>0.16.5</version>
                    <configuration>
                        <verbose>true</verbose>
                        <autoPull>always</autoPull>
                        <registry>registry:5000</registry>
                        <images>
                            <image>
                                <name>foo</name>
                                <build>
                                    [...]

In case no images are present in the host machine, everything works fine.
This command produces the foo:latest image on the host machine and pushes it to my private registry

However, if the host machine contains an image tagged as registry:5000/foo:latest, the command still produces the updated foo:latest image, but it pushes to the registry the already existing registry:5000/foo:latest image, instead of the new one.

From looking at the code, it seems to me that this is some sort of expected behavior. But in that case, is there a way to configure the maven docker plugin to override in any case the existing registry:5000/foo:latest and push it?

[rhuss]

Your observation is correct, using a registry this way creates a temporary tag, which then is pushed and removed afterwards (that's how Docker works, there's no way to provide a registry in other way).

It avoids to overwrite or remove accidentally an already existing image, which I think is a good thing. For the next version I will break the build for this case so that at least you get aware of this. Another solution would be to temporarily remove the already existing image during the push, but this adds yet another step in the already complex (transactional) workflow.

Would this be ok for you ?

For your use case, you could add the registry as part of the <name> then you don't need the temporary tagging at all. You could also use property like in <name>${registryPart}foo</name> and set ${registryPart} to registry:5000/ for the cases you need it (either via -D from the commandline, or within a <properties> section, which even could be put into some Maven profile).

[KowKiller]

Hi, thanks for your reply.

Actually in some cases I need the image without the registry name to be produced.

I'll explain better my use case. I am setting up a continuous integration system using docker to bring up the environment to run acceptance tests.
I use maven docker plugin to build and push containers with the updated components after each commit on the components code.
Then, acceptance test jobs are trigger and they use docker-compose to pull images from the registry and execute acceptance tests.

Initially I used separated hosts for building images and running tests, and everything was working perfectly. When I started using the same hosts for both purposes, I noticed this issue.

An additional requirement, is the ability to the developers to run the acceptance tests on their local machines before committing. To do this, the dev can build locally the containers using the docker:build maven command and then it can run the acceptance tests bringing up the environment with docker compose, without using the registry at all.

For this reason, in some cases I need the image without the registry part, while in other cases I need the image with the registry part.

Anyway, the proposed solution will do the job. I'll just need to do some logic with maven variables to support both cases.
I asked here first to check if there was a "cleaner" way, like a configuration option to allow to override existing images. Something like <overrideImagesOnPush>true</overrideImagesOnPush>.
It would have helped to keep pom files and CI job scripts easier to read.
I'm not the only one maintaining this system, so I wanted to keep it simple to avoid mistakes by other people that ignore this behavior. But I guess that if the next version will break the build, we'll have an early feedback if the problem occurs again.

I'll let you know if this works!

Thanks,
Stefano

[KowKiller]

Hi, I tested the proposed workaround and it works fine.
I used different profiles for discriminating when the registryPart should be used or not.

Should I close this issue or do you want to keep it open to implement eventually a cleaner solution in the future?

Thank very much for your support!

Stefano