It does this – during every push to main – by checking each chart in your project, and whenever there's a new chart version, creates a corresponding GitHub release named for the chart version, adds Helm chart artifacts to the release, and creates or updates an index.yaml file with metadata about those releases, which is then hosted on GitHub Pages. You do not need an index.yaml file in main at all because it is managed in the gh-pages branch.
Do we like this process and want to continue using this action?
Another approach, slightly lighter-weight, would be to set up CD to publish the chart as an artifact to the GitHub Container Registry for this repo (eg ghcr.io/spinkube/charts/runtime-class-manager) and then users can install via helm using the oci:// reference functionality, eg helm install ... oci://ghcr.io/spinkube/charts/runtime-class-manager. Then we don't need to host ye olde chart index.yaml or create a GH release to hold artifacts, etc. (Helm has supported pulling from OCI registries for a few years now, since ~3.8.0)
This project has a pre-existing Release helm chart workflow, but I don't think it has actually released the chart yet. Maybe @voigt can double-check?
The workflow uses the helm/chart-releaser GitHub action which does the following:
Do we like this process and want to continue using this action?
Another approach, slightly lighter-weight, would be to set up CD to publish the chart as an artifact to the GitHub Container Registry for this repo (eg
ghcr.io/spinkube/charts/runtime-class-manager) and then users can install via helm using theoci://reference functionality, eghelm install ... oci://ghcr.io/spinkube/charts/runtime-class-manager. Then we don't need to host ye olde chart index.yaml or create a GH release to hold artifacts, etc. (Helm has supported pulling from OCI registries for a few years now, since ~3.8.0)Thoughts?