feature request: helm chart repository

[joakimhellum]

With reference to the to the README, it clearly states:

For now, we do not host a chart repository.

Because a Helm provider is now managed by HashiCorp, it would be very pleasent if a Helm chart repository also could be managed by HashiCorp. For example by using GitHub pages.

Then we don't have to first clone this repo or to download and unpack the chart, and we can very easily change the version of the Helm chart to be installed.

And then we could do everything in Terraform configuration, for example:

resource "helm_repository" "main" {
  name = "hashicorp-consul"
  url  = "https://hashicorp.github.io/consul-helm/"
}

resource "helm_release" "main" {
  name       = "consul-westeurope"
  repository = "${helm_repository.main.metadata.0.name}"
  chart      = "consul"
  version    = "0.1.0"

  set {
    name  = "global.datacenter"
    value = "westeurope"
  }

}

Please vote on this issue by adding a 👍 reaction.

[mitchellh]

Yes, we plan to support this soon. Let me check on some things and get back to you.

[TheMacStack]

took a while to work it out as it doesn't seem to be documented anywhere but this seems to work for sourcing the charts directly from github, i have trouble with using the resource "helm_repository" in non persistant ci/cd build container as it seems to need to persist some stuff client side (which is blown away after each build) and dont want to have to store charts in the tf source so was kind of desperate to find an alternative which seems below is currently the best way.

resource "helm_release" "consul" {
  name       = "consul"
  namespace  = "${kubernetes_namespace.consul.metadata.0.name}"
  chart      = "https://github.com/hashicorp/consul-helm/archive/v0.3.0.tar.gz"

  set {
    name  = "connectInject.enabled"
    value = "true"
  }

  set {
    name  = "connectInject.default"
    value = "true"
  }

  set {
    name  = "client.grpc"
    value = "true"
  }

}

[jboero]

I'd also love this to make our deployments a snap. While a gzip CI job would be great and always allow the latest to be fetched from here directly (not it would be nice to have a -latest gzip as well), there are other options, such as using S3 for a private helm repo.

https://github.com/hypnoglow/helm-s3

As for security/gpg signatures / auth on the repo, that may require more work.

[DWSR]

@TheMacStack An easy-ish way to do this would be a git submodule. That way you're not storing the actual repository in your TF repo and you can refer to the helm chart through the use of ${path.module} as the repository.

[tongpu]

With chartmuseum it should be pretty easy to host you own chart repository. I've created one locally for myself and it works without issues.

Additionally there's been a very good talk at Helm Summit Europe how one can abuse GitHub Pages to host your own chart repository: https://helmsummit2019.sched.com/event/S8tT/get-your-helm-charts-out-there-reinhard-nagele-codecentric-ag

[jakesylvestre]

Any update on this?

[mogopz]

Agree this would be great to have!

We've just cloned this whole repository into our infra repo, but that will make upgrading quite fiddly. This seems to be the only helm chart that support sync catalog which is something we're relying on

[ishustava]

Hey all,

We now have our own Helm repository! Here are the instructions on how to use it.

I'm going to close this issue, but please let us know if you're seeing any problems with using our Helm repo. Thanks!