support for helm valuesObject

[pepordev]

Is your feature request related to a problem? Please describe. we have applications created with valuesObject configurations and this setup is not supported at the moment.

Describe the solution you'd like in the same way the updater work with helm values it could work with valuesObject inside an application.

    argocd-image-updater.argoproj.io/image-list: app=registry.example.com/image-example:X.x.x
    argocd-image-updater.argoproj.io/app.helm.image-name: image.repository
    argocd-image-updater.argoproj.io/app.helm.image-tag: image.tag
    argocd-image-updater.argoproj.io/git-branch: main
    argocd-image-updater.argoproj.io/write-back-target: helmobject:/apps/example/env/patch-application.yaml # the path to the application using valuesObject

[pepordev]

i do have a branch running with this feature, i will try to open a pr as soon as i write some tests for it.

[chengfang]

Thanks for the enhancement proposal. Can you share an example of your application.yaml and how does it construct valuesObject?

What're the benefits using valuesObject (externalized into a file) vs values file?

[pepordev]

Thanks for the enhancement proposal. Can you share an example of your application.yaml and how does it construct valuesObject?

What're the benefits using valuesObject (externalized into a file) vs values file?

An example application would be:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: example
  namespace: test-home
  annotations:
    ....
    argocd-image-updater.argoproj.io/write-back-target: helmobject:/apps/example/dev/app.yaml # path to this file in the git repository
spec:
  project: test-project
  source:
    repoURL: ghcr.io/stefanprodan/charts
    chart: podinfo
    targetRevision: 6.6.0
    helm:
      releaseName: example
      valuesObject:
        replicaCount: 1
        image:
          repository: registry.example/library/podinfo
          tag: 6.6.1
          pullPolicy: Always
        ingress:
          enabled: true
          className: nginx
          annotations:
            cert-manager.io/cluster-issuer: letsencrypt-production
            ingress.kubernetes.io/whitelist-x-forwarded-for: "true"
          hosts:
          - host: test.example.com
            paths:
            - path: /
              pathType: ImplementationSpecific
          tls:
          - secretName: test-example-tls
            hosts:
            - test.example.com
        serviceMonitor:
          enabled: true
          interval: 15s
          additionalLabels: {}
      version: v3
  destination:
    name: in-cluster
    namespace: test-example
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
      allowEmpty: false
    retry:
      limit: 5
      backoff:
        duration: 2m
        factor: 2
        maxDuration: 6m
  revisionHistoryLimit: 10

First of all, from our use cases, this configuration is way easier for developers than having multisource applications with external values files.

Secondly, we have helm applications that require extra resources likes external secrets, configurations or dependant resources where we deploy kustomize applications that contain helm applications where the kustomization git write target does not work as it does not detect the images being in use.

With this configuration, and what i've develop is a pretty similar behavior to argocd-image-updater.argoproj.io/write-back-target: helmvalues where the target path points to the application file and looks for the .spec.source.helm.valuesObject and update directly the application file in the git repository

[chengfang]

So this would directly modify application.yaml file? How do you make sure the change is limited to the valuesObject section? I suppose you will need to unmarshall, make changes, and marshall to application.yaml, and there could be changes to other sections, such as removing comments, whitespace and indentation changes, element ordering, etc.

[pepordev]

So this would directly modify application.yaml file? How do you make sure the change is limited to the valuesObject section? I suppose you will need to unmarshall, make changes, and marshall to application.yaml, and there could be changes to other sections, such as removing comments, whitespace and indentation changes, element ordering, etc.

There is an unmarshall step, but only the process looks for the valuesObject node and only this one is being modified and inserted in the same index as it was.

[chengfang]

So far we've tried not to modify application manifest directly. @jannfis what do you think? Does this enhancement fit well with the overall design?

[nilpntr]

@ppodevlabs could you share your implementation using helmobject. I'm also looking for a way to directly write back to the Application as I'm using valuesObject and not looking to write back to the helm chart git repo. Thanks in advance!

[pepordev]

@ppodevlabs could you share your implementation using helmobject. I'm also looking for a way to directly write back to the Application as I'm using valuesObject and not looking to write back to the helm chart git repo. Thanks in advance!

sure, you can build the project from this branch. Thats the one i'm using for testing

[pepordev]

@chengfang @jannfis any update on this? Now that the project is using yaml v3, it should be safer to adopt. ii've updated the branch with the latest changes