Helm: Provide a means of setting .Chart.AppVersion during install or upgrade without editing Chart.yaml

For clarity, #3555 was closed by the OP (ref https://github.com/helm/helm/issues/3555#issuecomment-633187773) with the following comment:

"It seems like a lot of people here are asking for a way to override the ‘appVersion’ field. The original intent/request in this issue is to allow —app-version as a replacement for —version, so a user could run ‘helm fetch —app-version=v0.15.0’ and Helm would work out what the latest chart version last specified v0.15.0 as an appVersion and fetch that.

In our project/chart (cert-manager) we want to make it as clear to end users as possible which version they are installing, so allowing them to install by app version instead of chart version would be a far more natural installation experience.

That said, this issue was opened 2y ago now, and since then we have opted to just keep both of these version numbers in sync/lock-step. After a couple of years doing this, it’s been surprisingly easy and pain free, albeit users sometimes have to wait a couple of weeks for a new official release if there are changes made to our deployment manifests.

Given the age of this issue, it’s length, the huge variety of slightly different feature gates, and the changes in the Helm project since then (Helm 3, OCI charts etc), I don’t think this issue is in a good state to be driven forward as a feature request in its current form. I’m going to close this issue, but anyone else who has a similar feature request Is best to open a new issue and link to any other relevant comments in this issue to provide evidence. Hopefully that’ll work better for the Helm team’s triage process so your requests can get the visibility they need!

I also think this sort of functionality could be, and probably is best, implemented as an external tool or wrapper around
Helm, especially when taking account of the OCI changes which I think would make this trickier to implement."

its ugly but it works, would love a built-in flag in helm though

sed -i "s/^version:.*$/version: $(git describe)/" chart/Chart.yaml
sed -i "s/^appVersion:.*$/appVersion: $(git describe)/" chart/Chart.yaml
helm upgrade app ./chart

I wish it was more like....

helm upgrade --version "$(git describe)" --app-version "$(git describe)" app ./chart

@loa Your suggestion doesn't follow the following from the title (and is the entire point of this"

without editing Chart.yaml

@timothyclarke I just wanted to clarify the use-case.

Currently without the ability of changing appVersion on upgrade, the result of helm history is:

REVISION    UPDATED                     STATUS      CHART           APP VERSION DESCRIPTION
1           Mon Jun  8 11:39:51 2020    superseded  spring-1.0.0    1.0.0       Install complete
2           Mon Jun  8 12:19:21 2020    superseded  spring-1.0.0    1.0.0       Upgrade complete
3           Mon Jun  8 12:20:51 2020    deployed    spring-1.0.0    1.0.0       Upgrade complete

Ideally running

helm upgrade --wait --app-version "$MY_AWESOME_VERSION" app ./chart

Wold result in a more user friendly helm history, like the one below. That shows that the chart has not changed but the app had new releases.

REVISION    UPDATED                     STATUS      CHART           APP VERSION DESCRIPTION
1           Mon Jun  8 11:39:51 2020    superseded  spring-1.0.0    1.0.1       Install complete
2           Mon Jun  8 12:19:21 2020    superseded  spring-1.0.0    1.0.2       Upgrade complete
3           Mon Jun  8 12:20:51 2020    deployed    spring-1.0.0    1.0.3       Upgrade complete

Does this use case fit with the helm process?

Ideally, would the app-version supplied via command line also be available in the templates ($.AppVersion)?

This would allow for it to be added to the Meta data of the kubernetes config.

This would be super useful. Remark on the topic of "app version" ie what is an app, and how do you define version when there is more than one docker image in the "app" etc, how to automate update in CI/CD. I bypass these issues by defining 2 versions:

1. the chart version: represents the _source_ for the template;
   
   
   
   • if the template source changes, the chart version should change; template source means the templates folder, the Chart.yaml, default values.yaml, helmignore, notes, etc.
   
   
   • I do not store helm chart in charts repo because chart is available from git at any time and can be installed via helm install
   
   
2. the installation version: unique value based on the combination of all values used at installation, ie after merging all values files (including decrypted secret ones) and set's and the chart's default values. I determine this via an MD5 or a SHA256 based on the final set of values.

Since helm does not have a concept of installation version, I use the app version to hold the md5.

This makes it to interpret what is installed:

REVISION    UPDATED                     STATUS      CHART           APP VERSION      DESCRIPTION
1           Mon Jun  8 11:39:51 2020    superseded  spring-1.0.0    3efe0e3...       Install complete
2           Mon Jun  8 12:19:21 2020    superseded  spring-1.0.0    ie21b02...       Upgrade complete
3           Mon Jun  8 12:20:51 2020    superseded  spring-1.0.0    3efe0e3...       Upgrade complete
4           Mon Jun  8 12:20:51 2020    deployed    spring-1.1.0    123abcd...       Upgrade complete

It is now pretty obvious that revisions 1 and 3 are the exact same installation: same chart source and same final tree of values.

If any one is interested in trying this out, https://github.com/schollii/sandals/blob/master/helm.py provides a couple of useful functions for this. Currently I get the hash via a dry-run to get the merged values, and I have to copy chart to a temp folder to edit the app version in Chart.yaml (or use the packaging workaround, since it supports --app-version). So --app-version for install would be awesome. I'd also like to implement something like --app-version-is-md5 which would make a dry-run unnecessary, but that'll be in another issue (#8453).

I use this before every install when I am not using a git tag yq w -i k8s/$CI_PROJECT_NAME/Chart.yaml appVersion "$CI_COMMIT_SHORT_SHA"

When I use a tag I upgrade the revision in the ci process I use this before every install yq w -i k8s/$CI_PROJECT_NAME/Chart.yaml appVersion "$CI_COMMIT_TAG"
Then commit the updated Chart.yaml to version control.

Using gitlab ci

I know there's lots of people that like to set the app version just before they publish a chart. But really we don't want to publish a chart especially when we are still testing the changes that we just made. install or upgrade to a dev environment is the primary use case for this feature.

@woodcockjosh, I'm not sure that this issue lies around the chart version, but more of the human readable application version (appVersion) that has been deployed using the chart.

I would say the primary use case for the feature is more to give the chart designers, server admins, and devs the ability to:

1. Easily see the version(not the chart version) of the application that is deployed. Where the application is the code and all dependencies needed. Note: I don't think appVersion would be a valid value to be used to uninstall, rollback, or search for releases.
2. (personal desire) To expose the value to the chart so that the chart maintainer, at their discretion, can determine if they would like to use the appVersion at time of install/update. Example would be to add it to the meta data of the Kubernetes deployment

By covering the two use cases above, IMO, it would allow for helm to stay un-opinionated on how the implementation and usage of helm charts is done.

the installation version: unique value based on the combination of all values used at installation, ie after merging all values files (including decrypted secret ones) and set's and the chart's default values. I determine this via an MD5 or a SHA256 based on the final set of values.

@schollii I like the idea of an instance version, but as a creator and implementor of helm charts where I work, I would still like a human readable app-version that is separate from the instance version. The reason for them to be separate is
the installation version would not be unique if only the application code changed and not the chart and/or values applied to the chart.

@rcampbel yes of course we want to see the version of the application that is installed. What I am saying though is that the circumstances under which you would want to have a different version for appVersion than the one that is in the Chart.yaml is if that chart belongs to you and you are deploying a development level version of the application. If it was not development level version then you could just keep the app version number inside the Chart.yaml and have the end users of the chart use that app version as the default app version.

If I am developing new microservices for example, I don't want to package and upload a new helm chart to a helm repository every-time I want to test a deployed version of my application. But I would also still like to see the version or commit id that is deployed for each release which is why we want to override the appVersion for development releases but probably not production releases.

What I am saying though is that the circumstances under which you would want to have a different version for appVersion than the one that is in the Chart.yaml is if that chart belongs to you and you are deploying a development level version of the application. If it was not development level version then you could just keep the app version number inside the Chart.yaml and have the end users of the chart use that app version as the default app version.

This is exactly why helm should stay un-opinionated on how the implementation and usage of helm charts is done.
Helm should not care about the deployment strategy to local and beyond, that is for the workflow of the team/project to figure out. But this is digressing from the feature that is being requested, allow for .Chart.AppVersion to be set at time of install/upgrade without updating Chart.yaml

I don't want to package and upload a new helm chart to a helm repository every-time I want to test a deployed version of my application

From what I can tell helm is already un-opinionated on this, since it has the means to do exactly this when calling helm upgrade

The chart argument can be either: a chart reference('example/mariadb'), a path to a chart directory, a packaged chart, or a fully qualified URL. ~https://helm.sh/docs/helm/helm_upgrade/

@woodcockjosh There are many use cases and as @rcampbel states helm should stay un-opinionated on this and allow people to work in their own ways.
If I follow the "should be published in the chart" logic (to the extreme) why does helm have the --set or --values,-f flag and for that matter why have a values.yaml file at all? Everything provided by the flags are deployment time overrides that should have been in the published chart. I know it's bad to put secrets into a chart, but if that was the only reason then the arg should be --secrets rather than --values.

In my situation we deploy a number of apps that use the same chart. These apps are promoted through environments using a CI/CD method. The apps make use of the --values flag to provide app specific and environment specific config (generally ingress and data source details). If I was publishing a new chart for every app version for every environment I'd be creating hundreds to thousands of chart versions per week. In most instance the only differences would be the app version. I'm then forced to bump the chart version. To me the requirements introduced by this entire paragraph, while logical with one thing triggering another, are crazy.

As the existing .Chart.appVersion is not working for us we have reverted to a static .Chart.appVersion and are using .Values.image.tag (This is not an invitation to re-open that debate)

I was sure appVersion was the way to go regarding the application version after reading the documentation, until reading all of this valid use cases.

For users of a chart package is easier to bump image.tag, it implies modifying only the values, the chart may live somewhere else. But by using image.tag you don't get information about the package version when doing helm history <release>

I've noticied as well that helm package <chart> will generate a tar file with the Chart.version. If you only want to distribute a new version of your app, and appVersion is used, you are expected to bump version as well, otherwise you'll overwrite the previous file. If appVersion and version are different, is harder to calculate the correct semver bump with automatic tools for version (suppose appVersion is bumped based on the commits messages). How do you people deal with it?

We just need something that is a real app version we can see when listing deployed charts.

When I have a helm chart which is created to deploy my standard microservice than I'd like to choose during deployment which app version this microservice has during deployment. Currently, all of my services having forever appVersion 1.0.0 and I'm not using helm to check which version of the application I have - because making this possible with current methods (repackage the chart) will make my life a living hell.

Just, please let us decide how we will be using this parameter. If this is not possible because of some technical reasons please let us know why.

I prefer not to use "sed" as mentioned in 8194
Until this is solved (or not) Here is how i solved this in my CI/CD (GitLab):

Package the chart with the app-version, then deploy it.
I know that the Chart version is not meant to be the same as the appVersion, but in our case it is fine as a workaround.

Also there is no need to upload to a helm repo, but it is possible using the resulting CI artifacts (chart.tgz)

So if packaging first is not an issue , and you need a workaround for today ,you can use something like this.

deploy:
  image: alpine/helm:3.2.4
  stage: deploy
  environment:
    name: ${ENV}
  script:
    - helm package --app-version=${CI_COMMIT_TAG} --version=${CI_COMMIT_TAG} ${NAMESPACE}
    -  | 
       helm upgrade -i --wait ${CI_PROJECT_NAME} ./${NAMESPACE}-${CI_COMMIT_TAG}.tgz \
       --set image.repository="${CI_REGISTRY_IMAGE}" \
       --set image.tag="${CI_COMMIT_TAG}" 
    - helm history ${CI_PROJECT_NAME} -n ${NAMESPACE}
  tags:
    - kubernetes
  only:
    - tags

In the output i now have the versions available.

 $ helm history ${CI_PROJECT_NAME} -n ${NAMESPACE}
 REVISION   UPDATED                     STATUS      CHART       APP VERSION DESCRIPTION                                                                                                         
 45         Sun Aug  9 15:40:42 2020    superseded  prd-0.1.0   1.16.0      Upgrade complete                                                     
 46         Mon Aug 10 11:38:56 2020    superseded  prd-v0.2.25 v0.2.25     Upgrade complete                                                     
 47         Mon Aug 10 11:55:41 2020    deployed    prd-v0.2.26 v0.2.26     Upgrade complete                                                     
 Job succeeded

@haimari
Thanks for the snippet, for anyone looking there is another example earlier in this tread https://github.com/helm/helm/issues/8194#issuecomment-635879040 that achieves the same result.

This issue at hand however is that repackaging the chart is undesirable and helm maintainers are forcing that opinion and way of working. This request is that the helm be less opinionated and allow helm to be used in a way that better fits other parts of the community.
This issue and https://github.com/helm/helm/issues/3555 has explored the differences between .Chart.version and .Chart.appVersion, specifically how most public charts tie appVersion to the container tag which has forced the chart version to change simply because there is a new version of an app is released. While that might be a good assumption for the bulk of public charts, the assumption is not valid for a significant number of private charts. Hence this request to the helm maintainers to stop forcing that approach onto the community.

p.s. Your code snippet implies a chart version per release / per environment which would then superseded the need for setting image.repository and image.tag. I'd expect a step after repackaging to published the chart to a helm repo in the event you needed to re-deploy see https://github.com/helm/helm/issues/8194#issuecomment-658715462 above which explores that rabbit hole

@haimari
Thanks for the snippet, for anyone looking there is another example earlier in this tread #8194 (comment) that achieves the same result.

This issue at hand however is that repackaging the chart is undesirable and helm maintainers are forcing that opinion and way of working. This request is that the helm be less opinionated and allow helm to be used in a way that better fits other parts of the community.
This issue and #3555 has explored the differences between .Chart.version and .Chart.appVersion, specifically how most public charts tie appVersion to the container tag which has forced the chart version to change simply because there is a new version of an app is released. While that might be a good assumption for the bulk of public charts, the assumption is not valid for a significant number of private charts. Hence this request to the helm maintainers to stop forcing that approach onto the community.

p.s. Your code snippet implies a chart version per release / per environment which would then superseded the need for setting image.repository and image.tag. I'd expect a step after repackaging to published the chart to a helm repo in the event you needed to re-deploy see #8194 (comment) above which explores that rabbit hole

@timothyclarke Thank you for the information.

1. This is not a best practice but a workaround for _"Provide a means of setting .Chart.AppVersion during install or upgrade without editing Chart.yaml"_
2. There is no need to push the chart to a repository, This works with multiple k8s clusters directly from Gitlab.
3. It provides all that i need in order to have releases:

The image.repository & image.tag are set anyway in exactly the same way at the pipeline,
so even without the packaging line, this is the way to use helm from gitlab.

the CI_COMMIT_TAG variable contains the current release tag of the pipeline that run.
So we can always roll back to previous version directly from the CI pipeline with one click.

My company has our helm chart decoupled from the container tags. There's absolutely no need to repackage the chart for every container build.

The absence of the option to set appVersion (and hence always having it set to the same value) during the install is a huge deficiency in our deployment process. It is really annoying that our users cannot see the application versions by doing "helm list"

Having the ability to use something like "helm install ... --app-version v1.2.3" would add a lot of value to using Helm in our case.

My proposal would be to deprecate appVersion and list chart version and container tag when doing helm list or helm history <name>.
Helm shouldn't try to provide the actual app version inside the container, it should provide what it has at hand, the tag and the chart version, here some examples:

| CHART | CONTAINER TAG |
| ----- | ----- |
| 0.1.0 | 0.3.0 |
| 0.1.0 | 0.4.0 |

In the above example we can infer that the chart is being reused for different tags

| CHART | CONTAINER TAG |
| ----- | ----- |
| 0.3.0 | 0.3.0 |
| 0.4.0 | 0.4.0 |

In the above example we could potentially infer that the chart shares the same version as the tag.

The main downside of appVersion seems to be that it requires the package to be re-published, even if the chart has not changed, but the code inside the container has. Meanwhile, the tag of the container can be provided through values.yaml and doesn't need to be republished.

Alternatives

The simplest I think would be to list the container tag when doing helm list or helm history, but it would be weird to have an appVersion hanging around. This at least, would give some extra info, and people could ignore appVersion.

Another solution, instead of deprecating appVersion, it could be moved to the values.yaml, this way it would be detached from the Chart, preventing multiple republishes.

Thoughts?

@Woile what if your app has more than 1 container?

@Woile what if your app has more than 1 container?

You are right, considering that use case as well (sorry I was thinking about my use cases), I think moving appVersion to the values.yaml would improve the situation.

• helm list and helm history could remain the same
• you can have more than one container
• you don't need to re-publish each time, but you can if you want to keep the Chart and appVersion in sync.

What am I missing?

My preference would be allowing to control appVersion explicitly. It might be equal to container(s) tags, or it might need to be set to a different value (e.g. my install script looks for a given container repository/namespace/tag and then applies a regex to transform those to a user-friendly format to display the app version)

@woodcockjosh @Woile
My $0.02. The concept of appVersion is a good one from a helm ls point of view. The implementation is the issue I'd like to see corrected. Having multiple tags / versions in appVersion should be fine eg appVersion: nginx-1.16.0-php-7.5

I note that helm 3.2.4 has {{ .Values.image.tag | default .Chart.AppVersion }} so allows that sort of disconnect

Ability to select appVersion during install/upgrade would be the most preferred approach. It makes no sense in bumping the chart version every-time the appVersion changes as the chart itself is not changed. Linear progression of versioning is also not always applicable - especially for multi container applications getting deployed in different environments with different combinations of container versions. The suggestion of using same appVersion and chartVersion also bad because that forces appVersion to be semVer compatible. semVer is not the holy grail of versioning and the appVersion should be free to use whatever versioning scheme that is most appropriate for the application.

@bacongobbler Does this comment mean that helm plans to implement such a flag?

I think the introduction of app-version (in command line opt) and appVersion (in Chart.yaml) effectively provide a good way to see the version of an application deployed with a chart instance. But this also generate a lot of different questions and practices that need to be clarify.

• The goal of helm (chart) is to package & install resources in a kubernetes cluster (for an application).
• The app-version can be only provided at the package phase, so this information become a part of the chart.
• Stored in a helm repository (like a java or python artifact) the chart become immutable. So the app-version should never be overridden.
• At the other side during the install or upgrade phase, values allow to override any values of the chart (for environment customizations) but the appVersion can not.
• As we can see in many use cases the real version of the application is the image version provided by image.tag during the install or upgrade phase

My conclusion

• An umbrella chart can be considered as an aggregation of multiple charts (dependencies) that follow is proper lifecycle
• An umbrella chart is the only case where the appVersion is not directly linked to the image used.
• An application always provide a chart where in many case the app-version = image tag (so by transitivity to the application code)
• The source separation between the application code and the chart code just introduce some difficulties on the compliance between the docker image and the chart.
• Shared chart like a "spring-boot chart" need to be always used as a dependency in the application chart (Even if your application is only composed of this dependency) ... you do not deploy a shared chart but an application !

My current choice

• a shared chart only produce a chart with it's version and app-version is always empty (never used)
• a shared chart is never used directly to do a deployment.
• an application (component) chart always produce is proper chart, where chart version = app-version =image tag
• an umbrella chart follow is proper lifecyle where the chart version represent the app-version

Question / Idea

I dont' know why the app-version be introduced (maybe to cover the bad usage of shared chart).
I think it could be a good idea to remove it and introduce the capability to set the image tag at the package phase without use workaround like sed or yq.

Maybe a too long post but i require some feedbacks

@grazius
My understanding of your post is that the --set, -f and --values flags are bad and should never be used. All deployments are immutable and should be rendered into a chart, even if that chart is little more than values.yaml and the umbrella chart as a dependency. This chart should be rendered at (application) build time and published to a chart repo

In the above situation where are you storing secrets or similar sensitive information? Everywhere that I have worked those have been fed in via a --values file

For some context my deployments have effectively 3 elements which are versioned independently

• Chart
• Application
• (Environment) Config Values

If I change one of those I shouldn't be forced to rebuild any of the others. I'm typically using multiple environments so the applications can be tested before they go _live_. As such a deployment would like chart-v1.0 application_build-50 config_non-prod-v1.3 with the env config files stored gpg encrypted.
My CI platform is managing the application build, deploy, promote as the build flows from source through testing to production. If we need to re-deploy a historic version of the application we re-run those jobs.

Question: Why should we be forced to use a chart repository to store state that my CI platform handles out of the box ? We should never be installing any of this by hand

@timothyclarke just be sure to use the secrets plugin so that you can use encrypted values files

@timothyclarke Hello, Thanks for this first feedback ;)

• The advantage of a repository (like, pypi, maven central, docker registries for development) is that the generated artefact can be shared and published (for helm it's a tgz) with the assurance that is immutable.
• For values by environment (it's an other subject) they can be stored where you want (scm repo, dedicated solution like hashicorp for secrets, illumio for netpol, etc ...).

A chart provide default values.yaml (immutable for each chart version) that can be used (or overrided) by chart consumers.
For the Chart.yaml it's also a immutable part of the chart ... and the app-version is included in.

In your case, what is displayed in helm list for app-version ? 50 ?
If yes, how did you put the application version in the chart app-version in your pipeline ?

@grazius

A chart provide default values.yaml (immutable for each chart version) that can be used (or overrided) by chart consumers.
For the Chart.yaml it's also a immutable part of the chart ... and the app-version is included in.

Maybe I'm misunderstand what you are saying here, but this brings up the question of why even have an app-version if it is immutable for each chart version? So for every application version change there would have to also be a bump in the chart version, even if no other change was made to the chart? If so why even have the chart version or app version at all?

I think this also goes against what is being requested, "Provide a means of setting .Chart.AppVersion during install or upgrade without editing Chart.yaml" I believe what @timothyclarke said earlier in this chat sums up things quite nice: https://github.com/helm/helm/issues/8194#issuecomment-671331311

I think another Important thing to keep in mind is that not everyone has control over the chart being used, but may have the ability to pass in the image that is used and other values into the chart at time of deployment. In that case how would you suggest updating the app-version that is deployed?

The same issue here!
Considering the use of the --description flag as a workaround to provide some way to show the version of the application in the helm list 🤔

The app-version is really necessary when you build umbrella chart. For component chart, the interest of make evolve the chart version and the app-version separately is very low i think.

Maybe the main problem is that the type in the Chart.yaml is not precise enough? No way to differenciate an umbrella, shared or application chart

@grazius That's quite an opinionated response.
While it may be applicable for many open source projects it isn't as applicable to as many closed source builds. Please re-review this thread including all the various statements and usecases made as this request is not a request to remove .Chart.AppVersion from the spec of a chart. It is not even a request to mask APP VERSION from the output of helm ls.
This thread is a request to make Chart.AppVersion configurable at the time that a chart is used (without having to rebuild or otherwise alter the chart) so that the APP VERSION field of helm ls is not misleading.

As it stands I would currently argue that APP VERSION is a superfluous field in helm ls and should not be visible to runtime commands because of how closely .Chart.AppVersion is tied to .Chart.Version. helm inspect chart --version <.Chart.Version> <.Chart.Name> provides the same information.
I'd also extend that into the use of .Chart.AppVersion to be used as the container tag as they are all slightly different things what can be versioned independently for valid reasons, but are currently shoehorned into a single thing.
I've tried to keep my opinions on that linkage outside of this request as projects can have entirely valid reasons for such a linkage. By not forcing the same process onto everyone that uses helm we make helm a better and more inclusive tool.
I don't think these requested changes lessen helm or force their usage onto others.

@bacongobbler Can you please comment on this? Its a highly requested feature

Its a highly requested feature

Hi, @jasondamour - thanks for your interest! Two good options: creating a helm plugin, and writing a HIP.

Hi, maybe the best solution is to provide a release-app-version argument for the install/upgrade command that if present override the app-version display when we do a helm list.?