Let us review this helm chart from Tilt codebase. It consists of a canonical helm chart for a web application that can be accessed from the internet. This translates to a few Kubernetes resources such as Service Account, Deployment, Service, Ingress, HPA.
This seems to be a good candidate for helm chart generation. Such a chart can be generated as part of bootstrapping process. End users only bother filling the values.yaml as per their needs. This helps avoid the learning curve & boilerplate associated with Helm chart (e.g. one needs to learn templating, troubleshooting yaml, etc.). In addition, this ensures the charts to adhere to best operational practices.
If one notices carefully, there is even a Pod to test the helm installation via helm annotation hook. Tiltfile & a script file is available to deploy the Helm chart into a Kubernetes cluster. These addons / benefits may increase as modern tools come up solving specific pieces to achieve developer agility.
To be precise, complimenting Tiltfile with Helm Chart opens up a lot of other avenues which this project (idl-gen) is trying to accomplish. Things like Inner Development Loop can be more practical for developers who do not need to care about Helm, Kubernetes, Tilt & so on.
Thinking further, if user want to operate the Helm resources as a Kubernetes custom resources they may use solutions such as k3s-io/helm-controller, fluxcd/helm-controller, etc. The best thing that these solutions provide is enabling end users to employ Kubernetes native constructs without writing any lines of controller code.
Problem Statement
Let us review this helm chart from Tilt codebase. It consists of a canonical helm chart for a web application that can be accessed from the internet. This translates to a few Kubernetes resources such as Service Account, Deployment, Service, Ingress, HPA.
This seems to be a good candidate for helm chart generation. Such a chart can be generated as part of bootstrapping process. End users only bother filling the
values.yamlas per their needs. This helps avoid the learning curve & boilerplate associated with Helm chart (e.g. one needs to learn templating, troubleshooting yaml, etc.). In addition, this ensures the charts to adhere to best operational practices.If one notices carefully, there is even a Pod to test the helm installation via helm annotation hook. Tiltfile & a script file is available to deploy the Helm chart into a Kubernetes cluster. These addons / benefits may increase as modern tools come up solving specific pieces to achieve developer agility.
To be precise, complimenting
TiltfilewithHelm Chartopens up a lot of other avenues which this project (idl-gen) is trying to accomplish. Things like Inner Development Loop can be more practical for developers who do not need to care about Helm, Kubernetes, Tilt & so on.Thinking further, if user want to operate the Helm resources as a Kubernetes custom resources they may use solutions such as k3s-io/helm-controller, fluxcd/helm-controller, etc. The best thing that these solutions provide is enabling end users to employ Kubernetes native constructs without writing any lines of controller code.