Hi Teja, https://github.com/quintush/helm-unittest provides support for helm chart unit tests. Some alternatives are also listed in https://github.com/quintush/helm-unittest#related-projects--commands

Big +1 from me! When trying to automate chart uninstalls (e.g. in the context of operator-sdk's helm-operator), it is fairly unintuitive and complex to set things up in such a way to guarantee

JFrog https://Chartcenter.io services will be deprecated soon. Please read more about it at https://jfrog.com/blog/into-the-sunset-bintray-jcenter-gocenter-and-chartcenter/

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

Hi Mike, This seems like it could be very useful, especially during dev where there are more likely to be issues in the uninstall of the resources. Keeping the release would allow would give us a

So if I’m understanding correctly, you’re looking to validate that a particular resource provided by the user follows a certain schema. Kubernetes resources define a schema (also known as a

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