How should we be publishing Helm packages these days?

General
1

@pat-s pointed out to me in #10 - Helm charts pushed to packages reported as container packages - codefloe/forgejo-codefloe - CodeFloe - A code hosting platform for the modern age that there are a few different ways to publish Helm packages to Forgejo instances. It’s not clear to me yet though whether I’m doing it the old way or the new way in the script I put together for one of my projects.

I don’t have much experience with pushing Helm charts and so I started from helm push after reading about it in this Red Hat blog post from 2021.

When one runs a command like helm push etherpad-0.0.4.tgz oci://<QUAY_HOSTNAME>/helm (from their blog post), is this the way where the host is treated as a Helm registry or as an OCI repository? And is this the recommended way to do it these days?

2

There’s no “better way” technically, but it looks like that the trend goes more towards OCI packages.

The “helm” way exists since ever, it uses a repository-like concept and is supported by all tools that work with helm charts.

OCI is a protocol that allows for various types of “containers”, with helm being one of those types.
It has an advantage in that it can be used to install a chart with one command and doesn’t require adding the repository first.

However, not all apps support the OCI definition yet and some have just added it recently.

I personally just publish both alongside each other and leave the choice to users.

When one runs a command like helm push etherpad-0.0.4.tgz oci://<QUAY_HOSTNAME>/helm (from their blog post), is this the way where the host is treated as a Helm registry or as an OCI repository? And is this the recommended way to do it these days?

If you push to oci://, you get an OCI “container” package.

In all cases, you need to authenticate against the registry first. See here for an example.