Publish Helm chart to an OCI-compatible repo to support versioning

[tomkerkhove]

When we moved to this repo, we decided to move away from hosting our charts on https://kedacore.azureedge.net/helm over https://kedacore.github.io/charts. (see helm/hub#181)

Unfortunately, this means that we are losing our Helm chart versioning.

I'd suggest to publish our Helm chart to an OCI-compatible repo such as Azure Container Registry so that:

1. We can version our Helm charts
2. We can use releases on this repo to track changes
3. People who are using an older version can stick to an older chart

[jeffhollan]

Concern with this would be that OCI support for helm repos appears to be opt-in and expiremental? https://helm.sh/docs/topics/registries/#enabling-oci-support

[jeffhollan]

But like the idea of having versioned outside of just git commits. Also do love how easy hosting a chart from a GitHub pages is (what we are doing today). Open to options though

[jeffhollan]

Actually looks like we are snapshotting versions of the chart for each release. We currently have 2 chart versions: 1.0.0 and 1.1.0 and soon will have a 1.2.0

https://github.com/kedacore/charts/tree/master/docs

[tomkerkhove]

It looks like you are right:

❯ helm search repo kedacore/keda --versions
NAME            CHART VERSION   APP VERSION     DESCRIPTION
kedacore/keda   1.1.0           1.1.0           Event based autoscaler for Azure Functions depl...
kedacore/keda   1.0.0           1.0.0           Event based autoscaler for Azure Functions depl...

I've missed that part, sorry :/

I'd suggest to close it and keep as is then, ok?

[MShekow]

Helm v3 now fully supports OCI-based Helm charts. I was wondering whether this ticket could be reopened, and whether the KEDA Helm charts could (additionally) be pushed to some OCI registry.

Use case: OCI-based Helm chart hosting greatly simplifies accessing a Helm chart from a CI/CD runner when there are corporate network restrictions, with OCI-registry mirrors (which do not properly support synchronizing upstream ChartMuseum-based charts).

[tomkerkhove]

I'm happy to re-evaluate this - Any guidance or want to contribute this?

Did they close on how to use it? Because I recall OCI was a pain in the past.

(sorry for slow response btw)

[MShekow]

OCI with Helm used to be a PITA, but has become stable. The basic idea is that wherever you are pushing your Helm chart (I did not find the GHA-workflow), you also run helm push mychart-0.1.0.tgz oci://localhost:5000/helm-charts, as documented here. As for the registry, the location is entirely up to you, e.g. the GitHub Container Registry that you already use for the KEDA images anyway. E.g. ghcr.io/kedacore/keda-chart

[nlamirault]

Any news on this feature ? Thanks.

[tomkerkhove]

I don't think we have objections, but open to contributions as long as it does not cause breaking changes

[mkilchhofer]

I think the publishing process is manually, right? Or where is the code who creates new releases like this:

• https://github.com/kedacore/charts/releases/tag/v2.14.2

Looks like @JorTurFer created it?

[tomkerkhove]

It is manual indeed as we want to have things under control, not always ship a new one

[mkilchhofer]

@tomkerkhove Do you have a script for that which we could extend?
Or shall we create a pipeline for that (GH action) which can be triggered manually?

[tomkerkhove]

This is documented on https://github.com/kedacore/charts/blob/main/CONTRIBUTING.md#shipping-a-new-version.

@JorTurFer /@zroubalik Any concerns for automating through GitHub Actions? My only requirement is that it gets triggered on GitHub Release by a human, not for every commit.

[JorTurFer]

We could trigger the release in the same way that we use for the code and probably it'll make our life easier xD
About supporting OCI, I'd support both, the current approach and OCI.

My only requirement is that it gets triggered on GitHub Release by a human, not for every commit

Is this something open to discussion? I think that we could improve our chart release process with automatic releases on commits if we update the process to ensure the same quality. There are other projects that generate the release notes automatically from changelog files which we could require. I mean, there are options to ship helm chart automatically with a good quality if that's your afraid

[zroubalik]

Agree with @JorTurFer

[romankor]

Any updates on that ? This could seriously help us setting up auto upgrades with flux cd , that heavily relying on OCI repos