Doesn't handle different registry structures well?

[perezjasonr]

Describe the bug

If registry in the source spec and the desired target registry have different structures it seems to mix and match them (or something).

For example my annotations might be this:

annotations:
    argocd-image-updater.argoproj.io/image-alias.force-update: "true"
    argocd-image-updater.argoproj.io/image-alias.kustomize.image-name: registry.gitlab.com/my/group/fluent-bit:1.5.2
    argocd-image-updater.argoproj.io/image-list: image-alias=registry-1.docker.io/fluent/fluent-bit:1.5
    argocd-image-updater.argoproj.io/write-back-method: git:secret:argocd/git-creds

where registry.gitlab.com/my/group/fluent-bit:1.5.2 is whats there in the repo which Id like to be replaced/updated and registry-1.docker.io/fluent/fluent-bit:1.5 is just a simple docker hub reference for testing as a proof of concept

but this results in trying to list tags at: https://registry.gitlab.com/my/group/v2/fluent/fluent-bit

Why is it trying to do a Get at "https://registry.gitlab.com/my/group/v2/fluent/fluent-bit"?

fluent/fluent-bit is from the image-alias.kustomize.image-name annotation, but its appending that to: registry.gitlab.com/my/group, which I provided with the image and tag directly "fluent-bit:1.5.2" (so theres no fluent/fluent-bit to be found there)

so I can't tell exactly how its building these paths but it looks like its mixing and matching them wrongfully.

To Reproduce

In your annotations have 2 registries that have differing paths:

argocd-image-updater.argoproj.io/image-alias.kustomize.image-name: registry.gitlab.com/path/one/image:tag argocd-image-updater.argoproj.io/image-list: image-alias=registry-1.docker.io/pathtwo/image:tag

and it will try to do a get using the first annotation but it will use the path from the second, which it will not find.

Or perhaps something else is going on but I cannot figure it out.

Expected behavior

I'm not sure which registry the Get call is trying to figure out (if its for the original or replacemnt) but If its trying to do a get at https://registry.gitlab.com/my/group/v2/fluent/fluent-bit/tags/list then it should have done https://registry.gitlab.com/my/group/v2/fluent-bit/tags/list (without the fluent). Or it could be the opposite it should have taken the fluent/fluent-bit and looked for it at docker hub.

Additional context

ive also tried docker.io/fluent/fluent-bit:1.5 or nothing (just fluent/fluent-bit:1.5, assuming its claim that it has docker hub by default), and it still tries to find the tags at https://registry.gitlab.com/my/group/v2/fluent/fluent-bit/tags/list

Is it the case that this tool expects two different registries to have identical structure/pathing? for example in the docs it uses 2 different registries, but both have the same argoproj/argocd path.

Version I used latest as of this morning which appears to be v0.9.5

Logs

Get "https://registry.gitlab.com/my/group/v2/fluent/fluent-bit/tags/list": http: non-successful response (status=404 body="404 page not found\n")" alias=image-alias application=fluentbit-es image_name=my/group/fluent-bit image_tag=1.5.2 registry=registry.gitlab.com

[perezjasonr]

As an update, i only seem to be having this issue with kustomize. That attempt to "GET" seems to be at the root of the issue.

I was able to accomplish the same with helm using image updater, these annotations which mirror the same goal worked:

argocd-image-updater.argoproj.io/image-list: jaeger-alias=docker.io/jaegertracing/jaeger-operator:1.21.2
argocd-image-updater.argoproj.io/jaeger-alias.helm.image-name: image.repository
argocd-image-updater.argoproj.io/jaeger-alias.helm.image-tag: image.tag
argocd-image-updater.argoproj.io/write-back-method: git:secret:argocd/writeback-creds
argocd-image-updater.argoproj.io/jaeger-alias.force-update: "true"

main difference is that I don't have to specify registry.gitlab.com/my/group/image:tag, which is what its provided in the actual values.yaml, so this successfully overrode it with the public docker image. and it never tried to do a GET for jaegertracing/jaeger-operator:1.21.2 at registry.gitlab.com/my/group (which wouldn't be there).

I was able to get the kustomize functionality I wanted but I had to forgo the image-updater and put the logic directly into the app object with param overrides:

kustomize:
      images:
      - registry.gitlab.com/my/group/fluent/fluent-bit:1.5.2=fluent/fluent-bit:1.5.2

So I feel like this should be doable with the image updater. I feel like its first trying to check for tags in the repo I'm trying to swap out, but I don't know why its checking there. Especially if one of the main concepts is that you can just put a placeholder there meant to be replaced, and why would a placeholder be checked

[jannfis]

Fix in #253 (released in v0.10.3) should have fixed that