Help with updating TAG

[bottlesbo]

Request for Assistance: ArgoCD Image Updater Not Updating Rollout Image

Dear [Team/Developers],

I am seeking help with an issue involving ArgoCD Image Updater during deployment. Although the logs indicate that the image tag was successfully updated, the changes are not being applied to the Rollout resource in Kubernetes. Below are the details of the problem and the current configuration.

---

Issue Description

• The ArgoCD Image Updater logs show that the image tag was successfully updated from 10055 to 10059:

  time="2025-02-09T15:06:31Z" level=info msg="Successfully updated image 'gitlab.sber.data1861.ru:5050/developers/frontend/frontend-landing-page/frontend-landing-page:10055' to 'gitlab.sber.data1861.ru:5050/developers/frontend/frontend-landing-page/frontend-landing-page:10059', but pending spec update (dry run=false)" alias=frontend-landing-page application=frontend-landing-page image_name=developers/frontend/frontend-landing-page/frontend-landing-page image_tag=10055 registry="gitlab.sber.data1861.ru:5050"
  
  

However, the new image tag (10059) is not reflected in the Rollout resource in the cluster. The changes remain in the "pending spec update" state, and the deployment does not proceed.

apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
  name: app-chart-rollout
  namespace: argocd
spec:
  generators:
    - git:
        repoURL: [email protected]:devops/helm-data1861.git
        revision: HEAD
        directories:
          - path: app-charts-rollout/frontend-landing-page
  template:
    metadata:
      name: '{{path.basename}}'
      annotations:
        argocd-image-updater.argoproj.io/image-list: '{{path.basename}}=gitlab.sber.data1861.ru:5050/developers/frontend/frontend-landing-page/frontend-landing-page'
        argocd-image-updater.argoproj.io/write-back-method: argocd
        argocd-image-updater.argoproj.io/{{path.basename}}.update-strategy: semver
        argocd-image-updater.argoproj.io/git-branch: main
        argocd-image-updater.argoproj.io/{{path.basename}}.helm.image-tag: "image.tag"
    spec:
      project: data1861
      source:
        repoURL: [email protected]:devops/helm-data1861.git
        targetRevision: HEAD
        path: app-charts-rollout/{{path.basename}}
        helm:
          valueFiles:
            - envs/common/commonenv.yaml
            - envs/dev/values.yaml
            - envs/dev/env.yaml
          parameters:
            - name: image.name
              value: gitlab.sber.data1861.ru:5050/developers/frontend/frontend-landing-page/frontend-landing-page
            - name: image.tag
              value: '{{image.tag}}'
          version: v3
      destination:
        server: https://kubernetes.default.svc
        namespace: '{{path.basename}}'
      syncPolicy:
        automated:
          prune: true
          selfHeal: true
        syncOptions:
          - CreateNamespace=true

image:
  repository: gitlab.sber.data1861.ru:5050/developers/frontend/frontend-landing-page/frontend-landing-page
  tag: "10055"

Observed Behavior
The Image Updater logs indicate that the update process succeeded, but the updated tag (10059) is not applied to the Rollout resource.
There are no errors in the logs, but the Rollout continues to use the old tag (10055).
Expected Behavior
The new image tag (10059) should be applied to the Rollout resource, and the deployment process should proceed automatically.
Questions
Are there any additional settings required in the ApplicationSet or Helm Chart to ensure the updated image tag is applied to the Rollout resource?
Could the issue be related to passing the image.tag parameter in the Helm Chart?
Are there any specific debugging steps or configurations that we should check to resolve this issue?
Request
Please review the provided configurations and logs to identify possible errors or missing steps.
If possible, share guidance or an example of a working configuration where the Image Updater successfully updates the Rollout resources.
Thank you in advance for your assistance. If additional data or logs are required for further analysis, please let me know.

[huehnerhose]

I do not have an answer, but the same question/problem.

And would like to add how the subquestion: How does this work with git as write-back-method?

[chengfang]

If you're using appset, there are similar issues reported, and possible solutions in #400