Digest strategy inconsistently writes tag names causing infinite commit loop with suffixed tags (e.g., latest-bookworm)

[p-paul]

Describe the bug
When using the digest update strategy with image tags containing suffixes (e.g., latest-bookworm, latest-buster-grib-nc), the Image Updater inconsistently writes the tag name in the git write-back file. It alternates between preserving the full tag name and stripping it to just the base tag, causing an infinite loop of unnecessary git commits even though the actual digest hasn't changed.

To Reproduce
Steps to reproduce the behavior:
Configure an ImageUpdater CR with multiple images from the same repository using different tag suffixes with the digest strategy:

apiVersion: argocd-image-updater.argoproj.io/v1alpha1
kind: ImageUpdater
metadata:
  name: example-app
spec:
  namespace: argocd
  commonUpdateSettings:
    updateStrategy: digest
  writeBackConfig:
    method: git
    gitConfig:
      repository: git@example.com:org/repo.git
      branch: main
  applicationRefs:
    - namePattern: example-app
      images:
        - alias: image-variant-1
          imageName: registry.example.com/myimage:latest-variant1
          commonUpdateSettings:
            updateStrategy: digest
            forceUpdate: false
          manifestTargets:
            helm:
              name: images.variant1.repository
              tag: images.variant1.tag
        - alias: image-variant-2
          imageName: registry.example.com/myimage:latest-variant2
          commonUpdateSettings:
            updateStrategy: digest
            forceUpdate: false
          manifestTargets:
            helm:
              name: images.variant2.repository
              tag: images.variant2.tag

Wait for Image Updater to run reconciliation cycles
Observe the git commit history for the .argocd-source-*.yaml file

Expected behavior
The Image Updater should consistently write the tag name in the same format. When tracking latest-variant2, it should always write:
value: latest-variant2@sha256:abc123...

Actual behavior The Image Updater alternates between two different formats in subsequent commits:

• Commit 1:
  value: latest-variant2@sha256:abc123...

• Commit 2 (next reconciliation cycle):
  value: latest@sha256:abc123...

• Commit 3:
  value: latest-variant2@sha256:abc123...

This creates an infinite loop where the Image Updater detects a "change" (the tag format) even though the actual digest (sha256:abc123...) hasn't changed, resulting in a new git commit every 2 minutes.

Additional context
The issue occurs when using tags with suffixes like latest-bookworm, latest-alpine, etc.
Both tag formats point to the same digest in the container registry
The digest values themselves are correct and match what's in the registry
Removing allowTags or using allowTags doesn't affect the behavior
The problem is in the write-back logic, not the tag selection logic

Logs
Example reconciliation cycle showing the inconsistent behavior:

time="2025-11-19T12:31:52Z" level=info msg="Setting new image to registry.example.com/myimage:latest-variant2@sha256:b7853ca1..." image_alias=image-variant-2
time="2025-11-19T12:31:52Z" level=info msg="Successfully updated image 'registry.example.com/myimage@sha256:d5b698ae...' to 'registry.example.com/myimage:latest-variant2@sha256:b7853ca1...'"
time="2025-11-19T12:31:53Z" level=info msg="git push origin main"
Next cycle (2 minutes later):
time="2025-11-19T12:33:54Z" level=info msg="Setting new image to registry.example.com/myimage:latest-variant2@sha256:b7853ca1..." image_alias=image-variant-2
time="2025-11-19T12:33:54Z" level=info msg="Successfully updated image 'registry.example.com/myimage@sha256:d5b698ae...' to 'registry.example.com/myimage:latest-variant2@sha256:b7853ca1...'"

Git diff showing the alternating format:

# Commit A
- value: latest@sha256:b7853ca1...
+ value: latest-variant2@sha256:b7853ca1...

# Commit B (next cycle)
- value: latest-variant2@sha256:b7853ca1...
+ value: latest@sha256:b7853ca1...

Version
ArgoCD Image Updater: v1.0.1

[dkarpele]

Thanks for reporting. Do you have the same issue with annotation based version 0.17?

[p-paul]

Hello,
I can confirm that this behavior is also present in v0.17; it behaves the same way as v1.0.1.

The last version I used that worked correctly was v0.12.2.

[dkarpele]

Hm,
Doc says:

Note that the digest update strategy will use image digests for updating the image tags in your applications, so the image running in your application will appear as some/image@sha256:<somelonghashstring> instead of some/image:latest. So in your running system, the tag information will be effectively lost.

Tag should not be in the target file at all!

[dkarpele]

This change was introduced by @chengfang in 0.15 here #815
But it seems the doc was not updated
@chengfang Could you have a look?