helm: BUG: helm validates the pre-run values of chart.metadata.version/appVersion when using `helm package` even if the flags to set those values are present and compliant.
Output of helm version: v3.5.x+
Output of kubectl version: N/A
Cloud Provider/Platform (AKS, GKE, Minikube etc.): N/A
Feature Request:
Helm package should not validate the chart.metadata.version or chart.metadata.appVersion if their “setter” cli flags are passed (as long as the values passed are valid semver). The workaround is to put 0.0.0 into each in the Chart.yaml but this seems like a needless constraint.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 15 (7 by maintainers)
Commits related to this issue
- Kubernetes and their stupid semvar checks https://github.com/helm/helm/issues/9596 — committed to derekpedersen/skatepark-api-go by derekpedersen 3 years ago
- Kubernetes and their stupid semvar checks https://github.com/helm/helm/issues/9596 — committed to derekpedersen/skatepark-api-go by derekpedersen 3 years ago
Why would we even care which versioning scheme someone uses? Why do we have to force SemVer on everyone? What’s wrong with having a commit hash as a version?
For me it means I cannot upgrade helm from 3.3.1 anymore. I didn’t to the introspection to find out which helm version exactly breaks literally every CI/CD pipeline I set up, but yeah. Why? Just let me pick my own versioning scheme myself, which fits for me.
Sure, no problem. I’m having commit hashes as versions for my custom helm charts. Usually, a helm chart lives in the same repo as the microservice it is supposed to deploy. So it makes sense to use the commit hash as a version for dev/preprod deployments. A prod deployment is triggered by a git tag, so prod deploys will have a SemVer version. So up until 3.3.1, this was no problem. Now, with
helm upgrade -iI get:And that is a big problem for me, as I have used this pattern in tens or even hundreds of microservices, which I set up the CI/CD pipelines for.
Ok, fair enough, but why do these cases have precedence over other cases? Who get’s to decide what’s more important? This means a lot of extra work for a lot of people. So that’s fine for you? Just to support one case where this might be useful?
Horrible, extremely narrow sighted decision, imo. If you take away the freedom, people might opt for something else…
In any case @loomsen, I don’t think your issue is the same as the one @SleepyBrett reported. Please open a new ticket with your findings and we can investigate further.
@SleepyBrett I had a closer look at https://github.com/helm/helm/issues/9298 and I think it’s the same issue as the one you described above. Can we close this issue in favour of that one, or is this distinctly different than that report?
Ok, so this is decided an there’s no going back? I guess that’s it for me with helm then.
edit I have a hard time believing this. How in the world can you introduce such a breaking change with a minor version update… Beyond my understanding, especially if you’re such a SemVer advocate.
I wonder who gets to decide things like this? My question why one use case is more important than others still stands…
I think this has to be reverted immediately, and made optional. Go ahead and make it mandatory in Helm 4, but give people the chance to adapt!
Ya’know what. This isn’t a feature request. This is a bug.