search

diggerhq / helm-charts

Apache License 2.0
8 stars 6 forks source link

remove appVersion from chart.yaml #14

Closed motatoes closed 2 months ago

dannysauer commented 2 months ago

In terms of removing the App Version... Generally with an upstream chart, what consumers expect is that the chart has been tested with the defined version of the package specified. When you have just one "main" container, using AppVersion as the default when values.image.tag (or equivalent) isn't specified is the "standard" behavior.

It allows one to inspect the chart with helm inspect/show, as in

sauer@fabulinus:~$ helm -n cert-manager list
NAME            NAMESPACE       REVISION    UPDATED                                 STATUS      CHART                   APP VERSION
cert-manager    cert-manager    7           2023-11-05 21:55:33.770327854 -0600 CST deployed    cert-manager-v1.13.1    v1.13.1

Creating a release every time the helm'd application image is released allows situations like mine, where helm charts are automatically deployed from a repo via a tool like Argo-CD or flux, and the chart is updated using a tool like Renovate to open PRs against the CD tool's source repo. A new chart traditionally means an updated app, often with no other changes to the chart other than the AppVersion - and any changes necessary to accommodate the new version of the app, if any.

dannysauer commented 2 months ago

Note in the cert manager example, the chart version stays in sync with the app version. That's also pretty typical.

dannysauer commented 2 months ago

For an example I'm familiar with: I (SRE/release/whatever, not developer) inherited a monorepo at Determined where the helm chart lives alongside the application. I don't like it, but it's not worth changing yet.

It's not the perfect example (I definitely have some cleanup to do to that workflow), but what I do to publish helm releases there is use a machine account to check out the helm branch (github pages) and update it when there's a new release published in the main repo - which will include a helm chart as an artifact. The actual publishing process I use is less important than the fact that I'm using the release.published trigger (as well as a workflow_dispatch trigger to allow manual publishing of a specific version for whatever reason).

It should be pretty trivial to similarly on-release trigger a workflow in the separate helm repo by directly calling a dispatch action in the helm repo which checks the current / a specified version of the upstream digger package and if it's not already published, update the chart, test, and publish.

I don't really have a great solution for easing matrix testing of a helm chart with common variations of values files, though it's on my list of things to someday figure out better.

motatoes commented 2 months ago

Many thanks @dannysauer ! Clearly much that I have missed about workflows of helm consumers. Will then do the recommendation of using appversion as the default when tag is not specified and setting up rennovate