Hi Marvin, I believe the dependency entry should as follows ( `..` instead of `.` since the game-tracker chart is in the same parent directory as `teamdb-ui`: ``` dependencies: - name: game-tracker

Hi, I've got two charts on my filesystem - which are not uploaded yet to any repo. They are both located in the same directory. [zaphod@oc3027208274 helm]$ ls game-tracker teamdb-ui Snippet from

I'm newbie to helm and trying to understand and develop helm charts for my organization, so pardon my knowledge on the subject.This is my idea of sharing a common library configmap to access across

Yeah. versioning is always quite complicated. Distro's have had a lot more time to figure it out. If you look at the way distro's typically version things, you see something

Its a lot to unpack, but in https://github.com/pnnl-miscscripts/miscscripts there are scripts to: 1. automatically build containers with newest versions of dependencies 2. apply a new version number

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