Helm chart metadata naming convention

[alexef]

Summary

Introduce naming convention and expose chart annotations in the ui.

Motivation

When using helm as an application source, the only revision information shown is the version (as opposed to Git which offers: committer, commit message, date etc). Some users use helm the same as git (any commit to stable branch builds and pushes a new helm chart version). Being able to understand what generated a specific version would improve the experience.

Proposal

Using Chart annotations and the argocd.argoproj.io/ prefix, similar metadata can be exposed as well. These will be shown on the application details page and in the History and Rollback dialogue (the same as git metadata is shown).

[alexef]

Assume a chart has these annotations in Chart.yaml:

annotations:
  argocd.argoproj.io/commit-author: alexef
  argocd.argoproj.io/commit-message: this was my change

they will show up in "History and Rollback" dialogue like this:

[sbose78]

Interesting proposal!

Does this have to be "argocd.argoproj.io" or is there a naming convention already in use such that it is useful to tools outside of ArgoCD ?

[alexef]

I couldn't find any, here are the official docs - I believe the field is open by design.

[leoluz]

Adding proprietary Argo CD annotations would require helm chart writers to be aware of which tool will be used to deploy it. Ideally charts should be agnostic to that.

Another approach that we could take is instead of introducing proprietary annotations, consume the Chart.yaml file to extract metadata information that we want to display in Argo CD UI. Was this approach considered?

[alexef]

Another approach that we could take is instead of introducing proprietary annotations, consume the Chart.yaml file to extract metadata information that we want to display in Argo CD UI. Was this approach considered?

@leoluz yes, but see the spec, I would say the only relevant metadata is (and could be mapped to - in the in-house chart use case):

• description - commit message
• home - commit URL
• maintainers - commit author(s)

apiVersion: The chart API version (required)
name: The name of the chart (required)
version: A SemVer 2 version (required)
kubeVersion: A SemVer range of compatible Kubernetes versions (optional)
description: A single-sentence description of this project (optional)
type: The type of the chart (optional)
keywords:
  - A list of keywords about this project (optional)
home: The URL of this projects home page (optional)
sources:
  - A list of URLs to source code for this project (optional)
dependencies: # A list of the chart requirements (optional)
  - name: The name of the chart (nginx)
    version: The version of the chart ("1.2.3")
    repository: (optional) The repository URL ("https://example.com/charts") or alias ("@repo-name")
    condition: (optional) A yaml path that resolves to a boolean, used for enabling/disabling charts (e.g. subchart1.enabled )
    tags: # (optional)
      - Tags can be used to group charts for enabling/disabling together
    import-values: # (optional)
      - ImportValues holds the mapping of source values to parent key to be imported. Each item can be a string or pair of child/parent sublist items.
    alias: (optional) Alias to be used for the chart. Useful when you have to add the same chart multiple times
maintainers: # (optional)
  - name: The maintainers name (required for each maintainer)
    email: The maintainers email (optional for each maintainer)
    url: A URL for the maintainer (optional for each maintainer)
icon: A URL to an SVG or PNG image to be used as an icon (optional).
appVersion: The version of the app that this contains (optional). Needn't be SemVer. Quotes recommended.
deprecated: Whether this chart is deprecated (optional, boolean)
annotations:
  example: A list of annotations keyed by name (optional).

[leoluz]

@leoluz yes, but see the spec, I would say the only relevant metadata is (and could be mapped to - in the in-house chart use case):

• description - commit message
• home - commit URL
• maintainers - commit author(s)

Agreed. We don't need all that for sure. Can we take this route then?

[alexef]

Okay :)