Rollback overridden by Image Updater even with write-back-method: git

[BSardorbek]

Description:
Hi,

I noticed an issue with rollback handling when using Argo CD Image Updater.

My setup:

Argo CD + Argo CD Image Updater

argocd-image-updater.argoproj.io/write-back-method: git

Image update policy like ~v0.1

Problem:

I pushed a new image v0.1.6.

Image Updater updated my Git repo automatically to v0.1.6.

Later, I needed to rollback, so I manually set the image tag in Git to v0.1.3.

After a short time, Image Updater again committed v0.1.6 to Git, overriding my rollback.

Expected behavior:

When I rollback in Git, I would expect Image Updater to respect that rollback (at least temporarily), instead of immediately overriding it with the latest tag.

Actual behavior:

Image Updater continues to enforce the update policy and reverts my manual rollback by pushing the latest tag again.

Question:

Is this the intended behavior?

Should rollback scenarios always be handled by disabling annotations or pinning a fixed tag?

Or is this a bug/feature gap where Image Updater should recognize rollbacks and not override them automatically?

[chengfang]

I see this as the normal behavior of image updater. After your manually changed the tag to v0.1.3 in git repo, argo-cd sync's up to the cluster, and image updater then sees that a new image version (v0.1.6) is available for the current version 0.1.3, and performs the updates as per the annotation configuration.

You can pin the image to a specific version in image-list annotation, or configure ignore-tags or allow-tags to restrict to certain versions if certain versions should be excluded (https://argocd-image-updater.readthedocs.io/en/stable/configuration/images/#filtering-tags)

You could also try digest update-strategy (https://argocd-image-updater.readthedocs.io/en/stable/examples/#digest) and make sure the tag (e.g., latest) points to the desired version.