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

Berin, I am not entirely sure of your workflow so these are just ideas and thoughts in the area. First, appVersion is optional. You do not need to use it if you don't want to. Second, if you are using

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

The usual way app versioning in Helm works is, the chart has a value that represents which image tag the chart should install. That tag in turn typically maps to the application version. This

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

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

Berin, A few things to address your template concerns. Firstly you can create your own chart starter packs (https://helm.sh/docs/topics/charts/#chart-starter-packs) which you can base subsequent

Berin, Thanks for such an extensive write-up. I can't address all of it now but I wanted to talk about transitive dependencies. I am curious what you are looking for in respect to that as far as

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

Thanks for suggesting the Kubernetes process. I'll take a look at it. I just took Gitlocalize for a spin. I had a couple problems with it (i.e., hugo front matter handling and DCO). Won't work for us.

Happy to chat about how k8s docs is doing it if you want! Most of the process is outlined here: https://kubernetes.io/docs/contribute/localization/ I would echo Chris' statement that it works out

Fedora and OpenStack use http://zanata.org It's notable the Kubernetes community just treats translations as code and that has served them decently, but they have invested in doing public "doc

I'm kinda interested in the human based tools more than automating translations. From what I've been told, the automation quality is so-so. But, we have people interested in translating docs. But, our

Sorry, missing link: https://azure.microsoft.com/en-us/services/cognitive-services/translator-text-api/ Matthew Fisher Caffeinated Software Engineer Microsoft Canada

Something I was interested in looking into was the Microsoft Translator API. From its description, > [...] that developers can easily integrate into their applications websites, tools, or any solution

The Helm website and docs are setup for localization / i18n. The flow of contributing translations is the same as contributing docs and code. This has left me wondering... should Helm use some outside

Hi, I'm a DevOps course student. I am now in the final project phase of the course, and I was required to deploy Prometheus operator via helm and grafana. Can you please, send me a link to a

Thanks Matthew, for your response. I don't believe the problem is with type. I tried with $, but getting the null pointer exception. <.Values.common >: nil pointer evaluating interface {}.mypath. I

In other words, you are passing a function a string when it expected an object. If you change your function call to the type it expects, that should solve your error. Matthew Fisher Caffeinated

In your example, you are passing a variable of type string ("need value") to your function "mypath". Inside your "mypath" function,. it's looking for an object with a field called Values. If you