You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
When setting up a new airgapped environment, I want to be able to move commonly used images referenced by my bundle over into the destination registry along with their original "tag". For example, when relocating docker.io/myorg/myimage:v1.2.3, which is referenced by a bundle, it is moved to DESTINATION_REGISTRY/myorg/mybundle:DIGEST and that prevents me from easily using the moved image from outside the bundle.
Describe the solution you'd like
When relocating docker.io/myorg/myimage:v1.2.3, which is referenced by a bundle, Porter could retag it to DESTINATION_REGISTRY/myorg/myimage:v1.2.3 and push to the destination registry the alternate name for the image. Porter should calculate the new tag by replacing the registry portion of the original referenced image with the destination registry. This will result in the image being "in" multiple repositories. The result should be a single image in the destination registry with multiple registry repository tags applied, and the image should retain the same signature/digest.
This should be configurable since the user may not have permission to create a new repository, or it may overlap with an existing repository that is not desirable to publish into.
Flag suggestions:
--retag=true
--preserve-tags=true (i.e. keep the original tags on referenced images)
--tag-strategy=TBD (allows us to use named behaviors that the user can select from)
This should not be the default behavior, as it can easily be considered a breaking behavioral change that would cause existing pipelines to fail (i.e. they don't have permission to push to library or other repositories in the destination registry).
Describe alternatives you've considered
A workaround is to manually do the retagging yourself in your bundle by reading the relocation mapping file and the original porter.yaml and figuring how how to generate the current location and the new desired tag.
Is your feature request related to a problem? Please describe.
When setting up a new airgapped environment, I want to be able to move commonly used images referenced by my bundle over into the destination registry along with their original "tag". For example, when relocating docker.io/myorg/myimage:v1.2.3, which is referenced by a bundle, it is moved to DESTINATION_REGISTRY/myorg/mybundle:DIGEST and that prevents me from easily using the moved image from outside the bundle.
Describe the solution you'd like
When relocating docker.io/myorg/myimage:v1.2.3, which is referenced by a bundle, Porter could retag it to DESTINATION_REGISTRY/myorg/myimage:v1.2.3 and push to the destination registry the alternate name for the image. Porter should calculate the new tag by replacing the registry portion of the original referenced image with the destination registry. This will result in the image being "in" multiple repositories. The result should be a single image in the destination registry with multiple registry repository tags applied, and the image should retain the same signature/digest.
This should be configurable since the user may not have permission to create a new repository, or it may overlap with an existing repository that is not desirable to publish into.
Flag suggestions:
--retag=true
--preserve-tags=true
(i.e. keep the original tags on referenced images)--tag-strategy=TBD
(allows us to use named behaviors that the user can select from)This should not be the default behavior, as it can easily be considered a breaking behavioral change that would cause existing pipelines to fail (i.e. they don't have permission to push to library or other repositories in the destination registry).
Describe alternatives you've considered
A workaround is to manually do the retagging yourself in your bundle by reading the relocation mapping file and the original porter.yaml and figuring how how to generate the current location and the new desired tag.
Additional context
The text was updated successfully, but these errors were encountered: