Broken handling of renamed images

[janpieper-gcx]

Describe the bug

The ArgoCD Image Updater seems to not correctly handle images that have been renamed via newName in the kustomization.yaml.

To Reproduce

ArgoCD application:

# ...
metadata:
  annotations:
    argocd-image-updater.argoproj.io/image-list: example.azurecr.io/example
# ...

deployment.yaml:

# ...
spec:
  template:
    spec:
      containers:
        - name: backend
          image: example.azurecr.io/example-test
# ...

kustomization.yaml:

# ...
images:
  - name: example.azurecr.io/example-test
    newName: example.azurecr.io/example
    newTag: v1.0.0

When pushing a new tag named v1.1.0, I get this:

# ...
images:
  - name: example.azurecr.io/example-test
    newName: example.azurecr.io/example
    newTag: v1.0.0                    # <-- wrong
  - name: example.azurecr.io/example  # <-- wrong
    newTag: v1.1.0                    # <-- wrong

Expected behavior

The image updater should check for the "final" image name that is used. So either name or, if available, newName.

# ...
images:
  - name: example.azurecr.io/example-test
    newName: example.azurecr.io/example
    newTag: v1.1.0

Having example.azurecr.io/example in the ArgoCD application, but example.azurecr.io/example-test as the "final" image name in the kustomization.yaml should not be a match.

# ...
images:
  - name: example.azurecr.io/example
    newName: example.azurecr.io/example-test
    newTag: v1.1.0

Additional context

None

Version

v0.11.0

Logs

None

[janpieper-gcx]

Seems like this can be used as a workaround for the moment 🤔

# ...
images:
  # change `example-test:v1.0.0` to `example:v1.0.0`
  - name: example.azurecr.io/example-test
    newName: example.azurecr.io/example
  # change `example:v1.0.0` to `example:v1.1.0`
  - name: example.azurecr.io/example
    newTag: v1.1.0

[jannfis]

You can set a renamed Kustomize image using the annotation argocd-image-updater.argoproj.io/<alias>.kustomize.image_name (refer to https://argocd-image-updater.readthedocs.io/en/stable/configuration/images/#custom-images-with-kustomize).

This works fine with the app source method, and should also work when writing Kustomization files.

[janpieper-gcx]

Okay, thanks for your answer. Will have a look 😉

1. Wouldn't it be better to use [...].image-name instead of [...].image_name? 🤔 Using - everywhere, but _ for the image name feels inconsistent.

2. Why can't we just lookup the image in the list of images by checking name and newName to find out what image needs to be updated? 🤔 Or does the image updater fully replace the list of images when it detects a new version of an image? If so, i would be interested in what happens with image definitions that are NOT managed by the ArgoCD application. For example when I have one image that is managed by me (e.g. for my application) and one generic nginx from Docker hub I don't want to update automatically?

Example:

# ...
  metadata:
    annotations:
      argocd-image-updater.argoproj.io/image-list: example.azurecr.io/example
# ...

# ...
images:
  - name: example.azurecr.io/example
    newTag: v1.0.0
  - name: nginx
    newTag: 1.21

[jannfis]

Wouldn't it be better to use [...].image-name instead of [...].image_name? thinking Using - everywhere, but _ for the image name feels inconsistent.

I think it actually is image-name, and that's a typo in the docs (which I c&p'ed into my reply).

Why can't we just lookup the image in the list of images by checking name and newName to find out what image needs to be updated?

If this is possible without side-effects, it would be fine of course. But I wonder, if you have more than one image in your application, how should Image Updater decide which of the entries to update with which new image? E.g. if you have more than one image that is updated to a custom image.