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.
4 Likes
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 latest).
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.
1 Like
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.
2 Likes
@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.
2 Likes
Resurrecting the thread - for those still interested, I found this: https://dille.name/blog/2018/09/20/how-to-tag-docker-images-without-pulling-them/
2 Likes
The use case is straightforward:
One: Git tags can be applied to a SHA at any time, and in particular long after that SHA has passed CICD. In particular it is common that not every git SHA will be tagged with a semantic version tag and it is relatively common that the version that needs to be shipped is an older commit. Here I’m assuming that version branches are not adopted for a project since for smaller teams that’s a lot of unnecessary overhead - and it makes CICD more complicated than just “ship specific commits from master” (this approach is pretty common in SaaS for small teams since patches can be always be deployed outside the normal CICD process).
Two: A docker tag should match a git tag for the sake of everybody’s sanity.
1 + 2 => It would make sense for a new docker tag to be applicable to an image at any time, e.g. after CICD is finished.
For this use case, downloading, building an image to add a semver tag is suboptimal. Especially when administering systems from low bandwidth environments (I know it’s hard to imagine but low bandwidth environments definitely still exist).
What’s more, applying a tag to an existing image without downloading the blobs is actually doable via the API (see message from @brodsky). What is not obvious from this thread is whether this is a supported feature and whether or not there’s some as yet unmentioned CLI capability for this.
@nathanleclaire can you clarify is this API functionality a supported feature and is there a way to do this in the CLI without downloading?
1 Like
I have exactly the same use case as so many others here. Images get stored in the repository with various tags, but I don’t know until later which one should receive a certain tag. We’re using AWS ECR, and I found this blog article that talks about how to do this using the AWS CLI commands: