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

The preferred method is requiring the user to set a value that points to an existing secret. If the user points to the wrong thing, then Helm should fail to deploy that release. We advise people not

Sorry, wrong email.-- Berin Loritsch DOMEX Architect 7921 Jones Branch Drive McLean, VA 22102 Email bloritsch@... Office (703) 735-6281 Mobile (571) 215-7708

Would 2pm work for you on monday?-- Berin Loritsch DOMEX Architect 7921 Jones Branch Drive McLean, VA 22102 Email bloritsch@... Office (703) 735-6281 Mobile (571) 215-7708

Hey Berin, I’m not sure if this completely answers the question, but the helm lookup function (https://helm.sh/docs/chart_template_guide/functions_and_pipelines/) may be usable here to

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

Hi all, Following the HIP guide. I am looking for feedback regarding my idea below: The current Helm uninstall implementation is marking release record as uninstalled even if Helm detected errors

There was no objections to the proposed dates for 3.6. So with today's 3.5 release the 3.6 dates can be announced as: 3.6 RC1: Monday May 17th, 2021 3.6 final release: Wednesday May 26th, 2021 Thanks

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

Hi, helm 3.5 will be released next week Wednesday, January 13th as previously announced. At the same time we should announce when the 3.6 release is planned. On the dev call today it was

Hi, It depends what you are doing with the helm charts? Mostly people install apps, many install pre-requisites (roles, clusterroles, crds, etc.) apart from the applications (pods). In case of

Hi, I was looking for the list of tests that can be executed or recommended to execute on a helm chart. Does anyone have a good handy list that can be seen as a good starting point? One observation,

Helm v3.4.0 and v2.17.0 were both released. Along with that the details on the new location for the stable and incubator chart repositories are available. Details are in the blog post at

Good morning/afternoon/evening (delete as applicable) I've been directed to this mailing list by Martin Hickey and Matt Fisher due to a proposal I have briefly mentioned at

Today, Oct 19th, is Helm's 5th birthday. Along with that we have an announcement about GitHub and the stable/incubator charts... https://helm.sh/blog/helm-turns-five/

The Helm Hub has now migrated to the Artifact Hub. Details are available in the blog announcement at https://helm.sh/blog/helm-hub-moving-to-artifact-hub/ If there are any questions or comments there

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

The Helm project has decided to deprecate the Helm Hub and redirect people to the Artifact Hub. We have been tracking this work for some time. We are now at the point where the redirect will go into

I wanted to share that we have made a small governance change to Helm. There was a section in the governance that pertained to the initial election of org maintainers. That event happened a couple

@Matt: I am trying to understand different test cases that can be tested via the helm test. I now agree that we need these tests but I was unsure how can help/aid my chart consumers. Most of the helm