field for app version for helm applications

[lienerieksta]

Summary

It would be extremely useful to have an additional field in the Application manifest to cover the actual application version in a situation when the chart is maintained (and versioned) separately from the application itself.

Motivation

I have a helm application that I want to configure a deploy notification for using argocd-notifications. The default on-deployed trigger references oncePer: app.status.sync.revision. In my case the revision (helm chart version) does not change so the trigger does not work. Unfortunately there is not another single field that I can reliably reference to achieve the desired behaviour of the trigger if I don't bump the helm chart version.

For a lot of in-house developed apps the chart almost never changes and therefore it's not optimal to repackage and push the chart each time a single container image tag changes. Also there are scenarios where it makes sense to use a single chart for a bunch of similar apps by just using separate values files.

On top of that if we assume that we don't use app version in container image tags, opting for build numbers and/or commit hashes, as is a popular practice, then the actual application version does not show up anywhere even near the Application and that is quite an important bit of information for it to be completely ignored in a CD context.

Proposal

I see two potential ways to solve this issue

1. Implementing an optional additional field in Application resource (and ideally depicting this info somewhere in the UI).

apiVersion: argoproj.io/v1alpha1
kind: Application
spec:
  source:
    helm:
      appVersion: <optional value> 

2. Changing values from a string block to a yaml. Not a direct solution to the issue, but it would allow to leverage it as a free form yaml structure for storing values that can be directly referenced in the Application object.
   There is a separate issue for this already that's just not getting any love: Make Helm values field templatable using Kustomize #2936

[artem-kosenko]

not sure 1 option will work, because you can not publish the helm chart with the same name and chart version (but another appVersion inside). You allowed replace existed one with --force key, but argocd ignore such "changes".

I build my apps like a helm charts in scope of application CI part and save them to S3, each app inside have dependency of the "base-app" helm chart (actually all k8s resources are inside this base-app, and apps put there only input parameters)
I case I update something inside the base-app chart I have to bump it's version and update dependency version in each apps' repo. I even try to publish base-app chart with the same version (replace it with --force kay), but looks like the argocd use some cache, and even I delete my app, argo install them with olde version of the base-app (that little strange for me). That's way I have to bump versions each time I change something inside.

as a workaround I think to use commit has and add it to the helm chart version, to make it uniq and avoid mount of tags in git repos. and yep, we have to build new chart each time we change any environment variables for it or something else.

As another variant we can deploy all this apps (helm chart with app values only) from git repository (that mean we have co configure mount or repositories and web-hooks on argo) but it this case we should not build new app-charts.

any way, I prefer 1st option and build app-helm chart within the application and the docker image. It much more time to wait in any changes, but allow to keep app code and deployment configuration for this version in sync.

p/s sorry for long post )

[artem-kosenko]

it will be really nice to see the "application version" next to the "REVISION" in argocd app history and next to the TARGET in argocd apps list commands
For now it is impossible to track the chart and app version separately as it was designed.
I use the chart version to track global release number, and applications inside has their own versions.

now no see the app version I have to check the manifest of it, or redesign versioning on the project and duplicate the app version in chart version (that is not a good option)

[lienerieksta]

not sure 1 option will work, because you can not publish the helm chart with the same name and chart version (but another appVersion inside). You allowed replace existed one with --force key, but argocd ignore such "changes".

The first point does not suggest using the appVersion field of the helm chart. As you pointed out, it would still require to repackage the chart.

Rather it's a suggestion to simply include an optional extra field in the ArgoCD Application CRD to be used to represent the actual application version not the helm chart version and show it in the UI. Whether to use the field and how to populate it, would be the free choice of the engineer responsible for the deploy pipeline.

[artem-kosenko]

Yep. I found such field that can be used to represent any kay:value (app version in this case too)

it was missed in the default chart but the fix is already merged.

https://github.com/argoproj/argo-helm/blob/master/charts/argo-cd/templates/argocd-server/applications.yaml#L42

I thing it might help you too

[lienerieksta]

@artem-kosenko

It's not a field, it's a list and therefore inconvenient to work with.

• If there are multiple info values I need to manage for the Application, I need to search the list for the correct value each time.
• I cannot reference a single info value in argocd notifications trigger oncePer field as that would introduce a new set of problems, like making sure that the list elements are kept in the same order at all times and that is an infrastructure landmine I'd like to avoid.
• it takes 2 clicks too many to get to the info fields in the UI - they are not in the app summary - people who are not deeply familiar with the setup see deceitful info in the app summary - it introduces fertile ground for miscommunication.

That said. it's how I'm working around the lack of this functionality at the moment. Just did not want to mention it, as it's not a good practice in my opinion.