Just out of curiosity does anyone know how helm would behave if we used ValidatingAdmissionController webhook to deny the helm release to be modified ? I bet you could rough it out with

> I wasn't aware you could do that. Is it common practice for someone to replace a chart for an in place deployment? A common use case is to migrate from a public chart repository (like one published

Thanks for the link to the PR. That seems a bit different than what I had in mind. Those are great questions to include in the proposal. Here's some basic answers and a question for

Hey Justin! I like this idea. We've had similar proposals presented for resource update locks like https://github.com/helm/helm/pull/5290, though there were several design flaws preventing that from

I would like to propose a process to "lock" a helm release to a specific version so it is safe from `helm upgrade` and other situations that may cause unintended breaking changes. There are a variety

Hi, Following the HIP process, I'd like to know whether the use-case below already received some thoughts, and whether there are some suggestions on best user experience to support this use-case. I

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