Support decentralized repositories

[helm]

Support decentralized repositories

[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: #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 "[email protected]"
+          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: github/roadmap#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