add workflow and documentation for OCI release

roobre commented 1 year ago

This PR proposes an alternative, and allegedly simpler and more modern approach to releasing this chart for easier consumption by users.

The problem

So far, the mastodon chart is not packaged in any way, making its use cumbersome. In my personal case, I need to have a hacky shell script downloading the latest .tar.gz from this repo and copying it to a charts/ directory by hand.

Alternative solutions

chart-releaser has been the de-facto standard for releasing charts for a long time. However, it has, in my view, several limitations:

It needs to (or is recommended to) run on every push to main. This makes hard to control when features are released.
It enforces the version specified in Chart.version. This means contributors need to bump this themselves, adding friction.
It (ab)uses github pages, which I personally don't find very clean.

This approach

For a long time, helm itself has supported publishing charts to OCI registires. I think this feature is awesome but for some reason it has not been widely adopted by the community yet. This PR implements that very same approach, which is simple and straightforward to implement, use, and understand.

How it works

First the version filed in Chart.yaml is set to 0.0.0. Maintainers or contributors do not need to touch this field anymore (but .Chart.Version will keep working in templates). Releases are triggered by creating a release in github, as it is customary with Github projects. The version of the chat is trivially derived from the tag that accompanies that version (e.g., release v4.0.0 will produce a chart version 4.0.0). This number is used by the helm package command to produce a chart package which is later pushed to ghcr.io as if it were a docker image.

Users can install the chart or add it as a dependency as normal, using oci://ghcr.io/mastodon/charts/mastodon as the chart url.

Other comments

I understand this is pretty much a maintainer decision, so It's okay if you don't like it. I opted for jumping directly with a PR because it took me very little time to adapt this workflow from other charts I manage, and because I think it's useful to "let the code do the talking". Looking forward to hear your thoughts!

Closes #27

jeremiahlee commented 1 year ago

@renchap I know you mentioned publishing the chart was on your to do list in February. Would you please consider merging this PR as a way of checking it off? It's a good solution and would help those of us running Mastodon on Kubernetes.

dunn commented 4 months ago

this is great, but i don't understand the rationale for setting the chart version to 0.0.0 and tracking the version number with the git tags. the chart version should be incremented, and git tags added to match.

roobre commented 4 months ago

@dunn The rationale is mainly to avoid having two sources of truth for the version (tag and file), which can easily get out of sync. Additionally, having to make a commit updating the version on a file adds extra steps to the release process, and adds friction to every rebase.

Is there any benefit from having the version in-tree? Keep in mind that the way it is done right now, helm package sets the correct version from the git tag, so the packaged chart has a real version in there (from the git tag) which users do see and use. The 0.0.0 version string is not visible to users.

dunn commented 4 months ago

it's not a hill i'll die on, but i think it's useful to have it in the repository as a reference, and if we're manually tagging anyway it (hopefully) won't be hard to forget to increment. (Alternatively we could set up a release script to manage both.)

mastodon / chart