cert-manager: Helm chart version is not SemVer-compatible
Describe the bug:
The chart version field on the cert-manager Helm chart is not semver-compatible as it includes a leading v (e.g. v0.12.0-beta.1). As a result, cert-manager is not listed in Helm clients which enforce SemVer, such as Octopus Deploy. (See also OctopusDeploy/issues#5220).
Expected behaviour: I expected the cert-manager chart to be listed in Octopus Deploy after I added the jetstack feed to our server, but only jetstack/tor-proxy is listed. The jetstack/tor-proxy chart does have a valid SemVer chart version.
Steps to reproduce the bug: N/A
Anything else we need to know?: Octopus’ support team responded with:
Looking through your index.yaml file, it looks like the cert-manager package is versioned with a leading v (i.e. v0.12.0-beta.1). The issue is this isn’t valid SemVer2, which we enforce even for helm charts. We understand this is an annoying limitation, and we have an open issue to support non SemVer2 versions which you can track here. https://github.com/OctopusDeploy/Issues/issues/5220
The SemVer spec states:
A normal version number MUST take the form X.Y.Z where X, Y, and Z are non-negative integers, and MUST NOT contain leading zeroes. X is the major version, Y is the minor version, and Z is the patch version. Each element MUST increase numerically. For instance: 1.9.0 -> 1.10.0 -> 1.11.0.
Environment details::
- Kubernetes version: v1.12.10-gke.17
- Cloud-provider/provisioner: GKE
- cert-manager version: v0.10.1
- Install method: Helm
As we’re currently stuck on cert-manager v0.10 because of the breaking changes in v0.11, please could the fix be back-ported to these earlier releases?
/kind bug
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 5
- Comments: 49 (10 by maintainers)
@jsoref I have verified that Flux works fine with the cert-manager Helm chart. PTAL at https://github.com/cert-manager/website/pull/1338
They use a version package which explicitly allows the
vprefix:@wallrj could you confirm that you’re saying that you’re intentionally breaking the Helm spec and not following the idiomatic pattern because your limited interaction still works? If so thank you for your time, but this conversation isn’t going anywhere.
This is a case where the Go principal of optimising for reads should be followed; you publish a chart once with a fixed workflow, then the chart gets downloaded many more times as part of significantly more complex workflows.
This should be reopened as it is most definitely a bug in this helm chart.
Other tools that are properly following Helm’s own documentation should not be forced to loosen their standards to accommodate a helm chart that isn’t following the rules.
Can this issue be reopened as it is not fixed ?
This is still an issue that violates the helm and semver specification, and breaks tools like argocd, flux …