Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use manifest-tool/docker manifest to "retag" manifests for staging? #31

Closed
StefanScherer opened this issue Jun 14, 2017 · 2 comments
Closed

Comments

@StefanScherer
Copy link

In our pipeline we use different tags for stages like unstable, testing, stable, ...
At the moment to retag an image we have to pull it completely, tag it and push the tag (which will be cached as no layer has differences). This is done on a separate machine that normally has no images pulled, so we don't want that pull as it takes time.
And thinking of multiarch/multios images for Windows and Linux this wouldn't be possible on a Linux machine as it can't pull and push Windows images.

So I tried the manifest-tool yesterday (with only linux/amd64 right now, so only one platform) to use it to remote "tag" an image. For the first step using real images as input it works, but for the next stage it only shows an error

$ manifest-tool push from-args --platforms linux/amd64 --template "org/app:testing" --target "org/app:production"
INFO[0000] Retrieving digests of images...              
FATA[0003] You specified a manifest list entry from a digest that points to a current manifest list. Manifest lists do not allow recursion. 

I then tried the "docker manifest" pull request, and it worked for that step as well. But soon I found out that it probably only worked because the manifest list only has one platform listed. I tried it with a multiarch image and the "docker manifest" command also comes up with the same error.

My workflow in mind would look like this:

docker_manifest

Any ideas how to support that with manifest-tool or "docker manifest" command?
Especially moving/retagging multiarch images would be interesting without pulling all images.

@estesp
Copy link
Owner

estesp commented Jun 14, 2017

Hey @StefanScherer can you let me know if you think #32 helps here? You would still need the YAML definition, but would allow you to roughly "remote tag" an existing tag, although it would do the calculations of cross-repo mounts, digests, etc. for the original tag first. Almost wonder if there is a use case here for a true "remote tagging" operation by just pulling the manifest (in your case the org/app:testing existing manifest list) and pushing it with the new tag. That would require no extra calculations or cross-repo blob mounts as the command would expect all that "worked" because the image/manifest is already in the registry.

@StefanScherer
Copy link
Author

Thanks @estesp. Between tagging "testing" and "production" there are running tests to multiple such images. When all the images pass the tests we want to tag all them that have the "testing" tag and tag it for next stage.
Otherwise we have to handle lots of different version numbers of each microservice (semver per service).
So #32 doesn't help here (but looks good to tag major-only, major+minor, ... tags 👍 ) as it is not at the same time to create both tags.
Any other idea/best practise to move several images that have independent version numbers from one stage to another?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants