All committers have signed the CLA.

You might want to use a vanity domain, like charts.temporal.io.

@sagikazarmark Good point, though the vanity domain can be added, or not, separately. It doesn't need to affect the publication script.

For example, localstack publishes their helm chart to http://localstack.github.io/helm-charts via gh-pages, and their charts repo can also be installed as http://helm.localstack.cloud/

rebased onto chart 0.2.3
@underrun PTAL

@joebowbeer I love this concept and we will definitely want to do this, but it's blocked on another more significant change: breaking apart the helm chart into one that only installs and configures temporal itself (which will be our production helm chart) and another that combines the separate temporal helm chart and charts for dependencies into something more like what we have today (and which we name clearly as a development chart).

part of the problem today is that there are production pieces and development pieces in the same chart and that's made it difficult to message about. if we're going to create a first class helm experience it really needs to start by having a chart we can say is entirely production ready without any caveats.

I've created an issue describing this: #189

I would argue that you need a place to host multiple charts first, otherwise where are you going to place your production and non-production chart? 🙂

Closing this for now as we will take a different approach to releasing the chart after our new approach to helm charts is implemented: temporalio/proposals#42