Get Helm Chart version available filtering by application version

[treezio]

Hi!

I would like to be able to get a helm chart as source filtering by the application version that it manages.

As an example, I would like to be able to get the latest chart version available for cluster-autoscaler chart filtering by the cluster autoscaler application version that fits my needs, as its compatibility is associated to a kubernetes version.

My scenario is the following:

I have a file where the cluster version is defined. I can scrape that value. using a file resource. lets imagine that it's 1.27

As cluster autoscaler versioning is associated to kubernetes versioning:
cluster-autoscaler 1.26.X -> kubernetes 1.26
cluster-autoscaler 1.27.X -> kubernetes 1.27
and so

I can get the latest version available for cluster-autoscaling filtering by the version scraped in the first step.

Then, having the latest version available for cluster-autoscaler that is compatible with my kubernetes version.

I'd like to filter the latest version for the cluster-autoscaler helm chart that uses the application version scraped in the previous step.

Then I could just update my gitops repository to point to that chart version.

After all this process, I'd expect to be able get chart version 9.29.5 which uses application version 1.27.2 which is the latest available for my kubernetes cluster version.

Is this something I could achieve using updatecli ? I did not see how to filter the helmchart resource by application version :(

I hope this is clear enough, Thanks !

[olblak]

Hey @treezio .

Is this something I could achieve using updatecli ? I did not see how to filter the helmchart resource by application version :(

It's not possible today.
That's an interesting scenario that I never though about.
I think for helm registries using https/http protocol, it should be easily done.
I had a quick look at the index.yaml like on https://charts.jenkins.io/index.yaml
There is a field appVersion similar to version so it should be straight forward to get and won't require additional API calls.
On updatecli manifest we could have a new setting ``appversionfilter with a similar behavior thanversionfilter`

Regarding OCI registries, I don't see how it could even work. Even if the appversion is exposed as annotation, this would imply a lot of API request. One to retrieve all versions and then one per version to retrieve annotation (assuming annotations contains the appversion)

I would need to do some investigation

[treezio]

Thanks for the explanation! This could be a great feature 🚀