Helm definitely has some wrinkles, and I've run into a few. So I would recommend separating your tasking. For example: Writing docker files and helm charts are separate activities, they deserve separa

You'll have to forgive my ignorance on this one, but there is nothing I can see that explains this design decision--and it really makes creating multi-service deployments harder than it should be. In

The idea is not to scan, but to validate that the specified secret is the right kind. I.e. the user specifies `example-secret`, and the helm chart fails if the secret that exists is not the right kind

Sorry, wrong email.

Would 2pm work for you on monday?

It appears this did not garner any attention. Is there any way to enforce constraints on a chart's dependencies? For example, I would like to have my chart enforce a specific _type_ of secret the cons

Example: I am creating a chart for a single page app server. In it I want the ability to add a reference to the TLS secret. The TLS secret would be provided by the person using the chart. In my chart

My understanding is that Terratest was designed around testing deployments and predates any testing code in Helm. I'm not on the terratest email distribution list so I don't know if they are even awar

Keep in mind that there is a tool called Terratest https://github.com/gruntwork-io/terratest that is designed to test your deployments. It works with a wide array of deployment tools, including Kubern

Out of curiosity, why wouldn't you simply have a master helm chart for the full application that declares all of the dependencies? As opposed to learning yet another tool (https://github.com/roboll/he

The complication I have is that the customer I have has very outdated concepts for approving and managing deployments. As a result, our devops pipeline is segregated from the production environment. H

As I dive deeper into the world of Kubernetes so that I understand what I need my charts to do, and how I intend to design the templates for my environment, I am curious how Helm ties things together.

It does help. The main thing I'm looking for is to wrap my head around the thinking into how versioning was designed to work with helm. It's a big difference between saying "yeah that's a thing that c

Right, in other words, build the chart for the upcoming release, but override the values in the CI/CD pipeline if that's how you work internally. Now, I attempted to do that using helm template direct

I'm in the process of writing up my recommendations for how to integrate Helm into our build and deployment infrastructure. I have a few questions that I need to understand better. The most important

Thanks for your response. I am creating starter templates, which will help once I've got the basics nailed down. I'm only on my second component and found things I needed to modify in the templates I

I'm in the process of modernizing our deployment to use containers and kubernetes to deploy a complex microservices application. The current deployment uses python scripts to place things where they n