Support version ranges in Helm Chart.yaml files in helmv3 manager

[patrickhuy]

What would you like Renovate to be able to do?

The renovate helmv3 manager (added in #5450) currently does not support version ranges.
Maintaining a Chart.lock file - and potentially specifying a version range in the Chart.yaml file seems common practice right now.
It would therefore be great if renovate could adhere to a specification of rangeStrategy for helm chart depedencies.

[viceice]

Can you please provide minmal reproduction repo ?

What i can see is, that helmv3 manager uses semver versioning by default, so it should support some ranges out of the box.

The helmv3 manager also supports lockFileMaintenance updates. So please precise your expected renovate behavior.

[rarkins]

What i can see is, that helmv3 manager uses semver versioning by default, so it should support some ranges out of the box.

I thought our semver had no concept of ranges. But if we used the npm semver type of versioning, then it might immediately support a majority of valid helmv3 range syntax.

[patrickhuy]

Thank you for the swift response!
Initially the feature request claimed that there was no support for lock file maintenance, that is incorrect, sorry for that, I edited it out shortly after creating the issue.

I've created a minimal reproduction repo for "range" support here: https://github.com/patrickhuy/renovate-helm-version-ranges
From the log I can see

            "currentValue": "6.*.*",
            "skipReason": "unsupported-value"

I'm not sure what kind of ranges helm supports, the helm documentation seems to refer to a semver spefication: https://helm.sh/docs/chart_best_practices/dependencies/ - I've mostly encountered 1.*.* style ranges so far, but according to the documentation others are also supported.
Enabling npm type versioning might work!

[viceice]

@patrickhuy What are you expecting to happen on your sample repo?

lock file maintenance should work even if some deps are unsupported but need to be enabled manually.

[patrickhuy]

In the sample repo I would expect renovate to create an update PR which bumps the dependency version to 7.*.* or - at least creates PRs to update the lockfile when new 6.*.* versions appear. It should not skip/ignore the dependency.

[rarkins]

Seems very similar to npm syntax for ranges, however one key difference is that go/helm treats 1.2 as a valid version while for npm it's a range (equivalent to 1.2.x or 1.2.* or ~1.2.0)

[viceice]

@patrickhuy you can enable lockfile maintenance to update the chart.lock to latest versions matching the range. For bumping the major you can maybe reuse npm versioning assigned via package rule.

If that works we can maybe easily add a new helm versioning based on npm versioning

[patrickhuy]

@viceice I was not aware that I could change the version matching, very cool that it's possible! I enabled it and it seems to work very well https://github.com/patrickhuy/renovate-helm-version-ranges/blob/main/renovate.json! Thanks a lot!

A specific "helm" versioning would be ideal.

[github-actions]

Thank you for providing a reproduction! 🎉 🚀

The Renovate team will take a look at the reproduction repository. Once we confirm the provided repository reproduces the problem, the label will be changed to reproduction:confirmed.

[HonkingGoose]

I've labeled this reproduction:provided because there is a minimal reproduction for range strategy.
I don't know if this is was what you guys need, so feel free to change the label if needed. 😄

[bacongobbler]

FYI, Helm’s version range syntax is described here: https://github.com/Masterminds/semver#checking-version-constraints

[viceice]

So helm is following semver v2 spec, so we should be able to use our semver versioning?