feat: being able to use git repo as custom catalog type.

[Bafbi]

Hi,

Currently only helm type is supported for helm charts catalogs.

Having to setup an helm charts repository is pretty bothersome, specifically from the fact that that a chart is just some manifest template, a metadata file (Chart.yaml) and a values file, and that the discovery can be done from folders in a repository.

The same way argocd and probably other gitops tools, we could add a catalog type that use a git repo as well as a directory in the repo for discovery.

[ddecrulle]

Hi Nathan, thanks for the suggestion!

To give some context on where we stand: we're currently working on adding OCI registry support as a new catalog type, which will be the next step beyond the existing helm (index.yaml) type.

That said, I want to be transparent about why adding a git-based catalog type — or any non-Helm catalog type — is non-trivial for Onyxia.

Onyxia doesn't just display catalog entries: it fully manages the lifecycle of what it launches. Today, this is tightly coupled to the Helm ecosystem:

• Discovery & configuration: we rely on values.schema.json to generate the dynamic UI for each service's configuration form
• Deployment: services are launched as Helm releases
• Runtime introspection: we use notes.txt, Helm release metadata, and Helm's state model to display service status, URLs, and contextual information to the user
• Lifecycle management: suspend, resume, and deletion are all driven through the Helm release abstraction

Supporting a git-based catalog (à la ArgoCD) would require either:

1. Wrapping git-hosted charts in a Helm-compatible layer at runtime, or
2. Building a parallel deployment/introspection/lifecycle stack for a new backend — which is a significant engineering effort

So while the idea is interesting, it's not on our roadmap in the near term. OCI support (which keeps the Helm model intact while removing the need for a chart museum) is the direction we're headed.

If you have a specific use case in mind, feel free to share it — it might inform how we think about catalog abstraction longer term.

[Bafbi]

I am not talking about not using helm chart format, but more about getting the chart from cloning a repo (could be latest and resync every x min, or ref a tag/commit) and checking folder from a directory of the repo for Chart.yaml, validate the chart format and packaging it (or not in fact helm doesn't care if it's in archive form or not), then it is just as good as any chart package to be use by the system.
So all of the Onyxia + helm point doesn't matter here.

1. Wrapping git-hosted charts in a Helm-compatible layer at runtime

None of that, a git host chart and helm repo one is the same thing, just on is put as archive for for distribution and not the other one, it's all just a folder with Chart.yaml and templates folder with templated manifest.

2. Building a parallel deployment/introspection/lifecycle stack for a new backend

Yes it is a new backend to add and this is in fact a bit on engineering effort for sure

The way I see it it's even better than having an oci backend, for exemple it would be a dropin replacement for the https://github.com/InseeFrLab/helm-charts-interactive-services catalog, just link this repo, set the charts directory as 'charts' and you don't even need the ci to package and create the index.yaml anymore