Helm Chart has the concept of Version and appVersion.
We are using the Version to document that a content of the Helm Chart changed or not (for ex, a template, deployment.yaml has new Envrionment value or a configmap.yaml has an additional) value, for these scenarios Version number should increase. We are using appVersion to document docker image tag changes (so actual Version of the Business Application, I know there can be multiple container images but we are able identify the one of those as main application and use its tag)...
Now in our development process there can be multiple valid images of the Business Application (feature development, lets say, feature1, feature2, feature3), so we can have a constellation like the following, Helm Chart: myChart Version: 5.1 appVersion: feature1, Helm Chart: myChart Version: 5.1 appVersion: feature2, Helm Chart: myChart Version: 5.1 appVersion: feature3 most of deployment are automated but there can be cases that we have to say somebody deploy feature2.
Now here comes the dilema, in our Helm Repository we would have these 3 charts.
5.1->feature1
5.1->feature2
5.1->feature3but when I look to the Helm Commands "Helm Install", "Helm Upgrade", "Helm Pull" I only see "--version" as parameter but no "--appVersion", so it is not possible to install
helm upgrade -i myChartFeature2 myChart --version 5.1 --appVersion feature2We don't want to version our charts, "5.1.0-feature1" because then we will loose our ablity to identify, we have a new Chart while something in the templates has changed or we have a new version while Business Logic has changed...
So my question is
Thx for answers...
AppVersion is just optional. Don't base anything on that except maybe a default fallback version of the app that the chart will install if not overridden.
Use a supplemantal --values file to override the image version deployed. values.yaml in the chart sets baseline defaults; subsequent values files supplied with --values or -f can be named something else, but each is merged and overrides anything given in previous files. --set has higher precedence than -f, but I wouldn't get into the habit of mix-n-match.
You can have an entire values file named some.yaml like this:
image:
tag: 1.2.3and that will override the image.tag in the default values.yaml, assuming you are using a structure like what helm create generates, though you can absolutely alter that design. Just add -f some.yaml onto the end of your command.
Or, use --set image.tag=1.2.3
appVersion doesn't work this way, it isn't involved in dependency management. It's just for humans to know "this chart packages version 1.2 of Foobar", though these days many charts support multiple versions of the underlying thing so it usually is just set to the default one, if it's set at all.