unable to list tags when image name contains a slash and is in the "library" namespace

[Lemmons]

Describe the bug argocd-image-updater is unable to properly find images with /s in the repository name which also are in the library namespace.

To Reproduce Steps to reproduce the behavior:

1. create an image/repository with a / in its name under the library namespace. For example my.private.registry/library/mynested/repo
2. add an annotation to update that image: argocd-image-updater.argoproj.io/image-list: myimage=my.private.registry/library/mynested/repo:v1.0.0

Expected behavior The image should be updated.

Additional context This bug is caused by a combination of the logic here in registry.go along with here in image.go.

You can see that image.go strips library from the image name, and then registry.go fails to add it back in (even with defaultns: library configured, since the check is very strict, and doesn't take into account a / in the registry name.

The end result is a list tags call to https://my.private.registry/v2/mynested/repo/tags/list instead of the correct https://my.private.registry/v2/library/mynested/repo/tags/list.

I think this can be classified as two separate bugs combining to cause this failure.

1. image.go is stripping a static string of library instead of checking if defaultns is set, only stripping if it is present, and using the value from defaultns for the strip string.
   There is a second, more subtle bug in this logic that prevented us from using a workaround. image.go is using strings.TrimPrefix which will trim all instances of the trim string, rather than just the first. So something like library/library/my-image becomes my-image whereas the correct logic here is to trim only the first library, which would result in library/my-image as the stored image name.
2. registry.go assumes there are no /s in the image name (len := len(strings.Split(img.ImageName, "/")); len == 1), resulting in it not adding back in the defaultns to the image name when the image name does have a / in it.

Version v0.11.3

[ltx0633]

I think I have encountered this problem. When argocd-images-updater writes back git, the mirror path will lose defaultns.When will the problem be fixed?

version: quay.io/argoprojlabs/argocd-image-updater:v0.12.2

[root@master ~]# kubectl get -o yaml cm argocd-image-updater-config apiVersion: v1 data: argocd.grpc_web: "true" argocd.insecure: "false" argocd.plaintext: "false" git.user: jenkins-ci kube.events: "false" log.level: debug registries.conf: | registries: - api_url: https://test-harbor.xxxx.com credentials: pullsecret:devops/docker-registries default: true defaultns: library name: harbor ping: false prefix: test-harbor.xxxx.com kind: ConfigMap

[ltx0633]

I think I have encountered this problem. When argocd-images-updater writes back git, the mirror path will lose defaultns.When will the problem be fixed?

version: quay.io/argoprojlabs/argocd-image-updater:v0.12.2

[root@master ~]# kubectl get -o yaml cm argocd-image-updater-config apiVersion: v1 data: argocd.grpc_web: "true" argocd.insecure: "false" argocd.plaintext: "false" git.user: jenkins-ci kube.events: "false" log.level: debug registries.conf: | registries: - api_url: https://test-harbor.xxxx.com credentials: pullsecret:devops/docker-registries default: true defaultns: library name: harbor ping: false prefix: test-harbor.xxxx.com kind: ConfigMap

Creating a new project in harbor solves this problem .That is, do not use the default "library" warehouse