charts
charts copied to clipboard
kedacore
Publish Helm chart to an OCI-compatible repo to support versioning
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 https://github.com/helm/hub/pull/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:
- We can version our Helm charts
- We can use releases on this repo to track changes
- People who are using an older version can stick to an older chart
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
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
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
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?
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).
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)
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
I don't think we have objections, but open to contributions as long as it does not cause breaking changes
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?
It is manual indeed as we want to have things under control, not always ship a new one
@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?
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.
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
