Support decentralized repositories

[sagikazarmark]

I think the centralized chart repository is a great pattern and fits several use cases (if not most of them), but I can think of more than one occasions when I wished it was different.

In many cases, keeping the chart close to the source is desirable. For example:

• the chart changes often together with the source and updating out of tree charts is a hassle
• testing the chart with the source code changes is much harder
• sharing common resources (eg. CRDs) with charts requires a lot of copy-pasting

Keeping a chart repository on GitHub has a lot of benefits: it's easy and cheap, easy to understand and setup with this great tool. The "centralized" chart repo (with all the charts in a single repository) is supported well by this action and it works great.

It would be nice if it supported a "decentralized" model as well. External repositories could create GitHub releases, uploading the chart package which another action (or I should say this action in a different "mode") could react to and update the index.yaml.

I believe the chart-releaser tool itself already supports this use case (is that actually true?). The question is whether this action could/should support it, or maybe it should be an entirely different action/set of actions.

What do you think?

(This issue might be a duplicate of #22, but I thought explaining a use case would be a better start for a conversation.)

[bitjson]

This would be an excellent workflow for my use case. I develop my charts in a monorepo with most of the application's source code; I'd like to have an action which releases the chart from that repo, saving it to a shared charts repo for my organization.

@sagikazarmark did you figure out a strategy for releasing charts from multiple projects into another repo?

[MurzNN]

Alternative of releasing charts from other repo can be gather releases from several github repos to a single Helm repo index.

For example, here https://github.com/300481/seafile-server we have a separate git repo for seafile-server chart with it's own releases and similar https://github.com/300481/shield with shield.

And instead of publishing all release archives to https://github.com/300481/charts repo as files (as done now) - we can generate index.yaml file with urls like: https://github.com/300481/seafile-server/archive/refs/tags/0.5.0.tar.gz instead of https://300481.github.io/charts/seafile-0.5.0.tgz

This way will keep external git repo as main source of code and releases, and convert Helm charts repo to only aggregator of needed charts, without storing duplicates of sources and release archives for each included chart.

And here is my feature request for this feature: https://github.com/helm/chart-releaser-action/issues/104

What do you think about this idea?

[MurzNN]

I've invented a good workaround for this task using git submodules, and seems it works well: Here https://github.com/murz-helm-charts/murz-helm-charts/tree/main/charts the matrix-hookshot is a git submodule that linked to external git repository. So before running releaser action we need to download all submodules via additional step: https://github.com/murz-helm-charts/murz-helm-charts/blob/main/.github/workflows/release.yml

       - name: Configure Git
         run: |
           git config user.name "$GITHUB_ACTOR"
           git config user.email "$GITHUB_ACTOR@users.noreply.github.com"
+          git submodule update --init

And all works well. As result I can have separate git repos for each chart, and one Helm repo with all releases.

Not such good as keeping releases in original repo, but much better than have one large monorepo mess...

[sagikazarmark]

Honestly, I think this is going to become less important once OCI support in Helm becomes stable (already happened in 3.8) and registries, like GHCR start supporting other artifact types: https://github.com/github/roadmap/issues/122

The latter has been delayed, but hopefully they will bump the priority, now that Helm OCI support is stable. If not, we can always use low-cost alternatives.

[maximemoreillon]

I would also love to have a way to keep my charts in their own individual git repositories