After testing has completed I’d like to take my image:latest image and create a release tag like image:1.3.1. Is it possible to tag from dockerhub to dockerhub without doing a pull, tag, and push? I don’t have any reason to download and upload it other than to change the tag.
No, it’s not possible.
Do you see how this could wreak havoc with access control levels if allowed? Just because I have access to registry A and B, does not imply that registry A or B should have access to the other.
Check out the
docker tag command, which might well solve your problem in the first place. If you
docker tag jeremypumphrey/foo:latest jeremypumphrey/foo:1.3.1,
docker push of both of those images to the same registry will do the lion’s share of the work only one time.
I’m not following your answer. For a single registry I can do a pull, tag (no build), and push. I’d like to do exactly that without pulling and pushing. I’m not insterested in crossing two registries. I run create and upload my :latest on one server, and if they pass the tag logic is on another server. That second server has no need to pull and push other than what is required in order to update the tag in dockerhub. I’m sure there are others wasting bandwidth and time pulling and pushing just to update a tag. I thought it might be a good feature request.
If the layers already exist and you
docker push with a different tag Docker will figure out there is nothing to push and report
Layer already exists for those layers.
Why do you need to tag and push from a different server than the one you originally build and push on? Wouldn’t it be easier to just tag and push always from the original server?
(In general I recommend always tagging your images and never relying on
In a CI/CD flow I build the image in one travisci step and deploy it to a test server. Then in a second travisci step I run some tests on the test server and if they pass I want to tag the :latest to :deployable-timestamp. The second step doesn’t have the image so I’m downloading, tagging, and uploading just to accomplish the tag.
Why not just tag the first image with the unique tag in the first place?
Would loved to have found a solution on this thread. Such is life.
@nathanleclaire because it’s common to want to rely on a specific type of version. Perhaps the idea is to always be using the “latest” version of some internal published thing by another team. One wants to know immediately when the most up-to-date dependency version breaks the downstream project. A different scenario is when wants to have the most up-to-date latest and stable version.
Of course, such strategies have drawbacks: every strategy does. For instance, the common, super-stable, production-grade strategy of depending on a specific version (e.g. commit hash or semver 2.0 scheme) gives repeatability at the cost of always delaying fixes and updates for newer dependency versions.
Different solutions for different problems.
@nathanleclaire I would love to see an update here. I have the same problem. In my environment, CI/CD produces an image, tags it
dev, and pushes it to a repository. When QA wants an update to their environment, each image is pulled by the tag
dev, tagged as
qa, and pushed back to the repository. After QA finishes testing, and is ready to deploy to production, the images are pulled by the tag
qa, tagged as
prod, and pushed back to the repository.
So this works very well, as nothing is ever rebuilt from source as it is promoted up through QA and Prod, which helps protect us from unexpected code from dependencies working its way in. The problem is this tagging procedure is done on machines that have few resources, and have absolutely no need for the image itself.