Helm repository as first class Argo CD Application source #1145

So far the only source for Argo CD application are git repos (followed by a path and a target revision). What about supporting helm repositories as Application sources as well?

Leveraging Official Helm charts

To leverage some of the official helm charts, we are creating Argo CD applications pointing to the helm/charts GitHub repo (where the resources of the official charts are managed).

Such application would look something like this:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: elasticsearch
spec:
  source:
    repoURL: https://github.com/helm/charts.git
    path: stable/elasticsearch
    targetRevision: 46b1348dccaa800ae75b46be7c3faf7adee9aecc
    componentParameterOverrides:
    - name: cluster.name
      value: my-elasticsearch
...

Problems with this approach:

1. No proper versioning. Instead of the helm chart version, we need to use the commit sha
2. All parameters need to be overridden using the componentParameterOverrides. This list can sometimes become very long (especially in these public charts) and cumbersome to manage
3. Only works for charts backed by a public GitHub repo

Helm repository as an Argo CD Application source

We may now be in a situation where teams would like to publish their charts (during a release step) into a Helm repo. In this case we would like to create applications pointing directly to the helm repo instead of the multiple GitHub repos which hold the actual templated manifests. In fact, we may not even have access to some of those GitHub repos.

What do you guys thing about supporting such application source?
Suggestion:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: elasticsearch
spec:
  source:
    type: HelmRepo
    repository: https://kubernetes-charts-incubator.storage.googleapis.com
    name: elasticsearch
    version: 1.9.2
    componentParameterOverrides:
    - name: cluster.name
      value: my-elasticsearch
...

This would address the issues 1. and 3. mentioned earlier.

The following workaround - #938 (comment) - has been suggested to address this issue. However, this truly feels like a hack and it quickly gets very tedious to have to create a shallow chart for every upstream original chart.

How to avoid the infinite list of componentParameterOverrides ?

The application changes suggested above would address points 1. and 3. but not really do anything about 2. I am also aware that a proposal redesign of the componentParameterOverrides is in progress here - #1141.

I would argue however that ideally it would be great to override values in helm charts in a values file like manner. What if instead of a list of parameters to be passed to --set during helm template, we would be able to specify a values object that would override the ones in values.yaml from the chart source.

Suggestion:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: elasticsearch
spec:
  source:
    type: HelmRepo
    repository: https://kubernetes-charts-incubator.storage.googleapis.com
    name: elasticsearch
    version: 1.9.2
    values:
      cluster:
        name: my-elasticsearch
      image:
        repository: "docker.elastic.co/elasticsearch/elasticsearch-oss"
        tag: "6.5.0"

fyi, some of it was inspired by the HelmRelease CRD by flux: https://github.com/weaveworks/flux/blob/master/site/helm-integration.md