[FR] Allow OCIRepository to be used instead of GitRepository for chart.sourceRef

[dex4er]

I use Helm charts from Git repository like:

apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
spec:
  chart:
    spec:
      chart: ./infrastructure/app/helm
      sourceRef:
        kind: GitRepository
        name: flux-system
        namespace: flux-system

I don't see any option to use it here an OCIRepository instead. I'm not quite sure if using HelmRepository with url: oci:// is a good alternative: I have a single artifact for a whole tree and I would like to avoid using multiple sourceRefs and multiple flux push commands if possible.

[hiddeco]

See .spec.type on the HelmRepository object kind: https://fluxcd.io/flux/components/source/helmrepositories/#type

We do at present not support building charts from OCIRepository objects themselves.

[dex4er]

@hiddeco This is the reason that I opened the issue: I can't just easily replace GitRepository with OCIRepository for Helm.

[aryan9600]

You need to replace it with HelmRepository with .spec.type: oci. OCIRepository is meant for general kubernetes manifests not helm charts.

[stefanprodan]

IMO OCIRepository is meant as a replacement for GitRepository, the content of an OCI artifact pushed by Flux is in no way limited to Kubernetes manifests, it can have anything inside Helm charts, Terraform scripts, Pulumi programs, cue, source code, etc.

[dex4er]

You need to replace it with HelmRepository with .spec.type: oci. OCIRepository is meant for general kubernetes manifests not helm charts.

But I don't want to use HelmRepository. I have my all charts in single Git repository and I use GitRepository for all of them. But now I can't use them because I need to use push rather than pull, and OCIRepository doesn't work with Helm controller.

I don't understand why you force me to create Helm repository and do separate artifacts for each Helm chart when I can have monorepo currently and all I would need is simple change from GitRepository to OCIRepository. Anything else would work the same way.

[stefanprodan]

@dex4er we'll discuss this feature request at the next public dev meeting and we'll get back to you afterwords.

[AleksanderBrzozowski]

@stefanprodan Are you planning to start working on this feature?

We have a very similar use case, we want to migrate from GitRepository to OCIRepository. We have a setup with HelmRelease that uses GitRepository as a sourceRef with reconcileStrategy set to Revision.

We can't use HelmRepository without making changes to the workflow, because the HelmRepository resource works only with ChartVersion.

I can try helping with the implementation, just let me know if the proposal is correct :)

[makkes]

I am in the process of fleshing out an RFC proposing to consolidate the different OCI API kinds. I'll very likely put up a PR in the flux2 repo next week.

[dex4er]

@makkes @stefanprodan Any news on this topic?

[willejs]

Sorry to hassle you guys, but any idea where this sits in the roadmap @makkes @stefanprodan ?

[stefanprodan]

My proposal is to use OCIRepository to fetch Helm charts from a container registry, which is very diffrent to this proposal, where an OCI artifact has many chart sources that Flux needs to build. Helm charts are meant to be packaged, versioned and pushed as a stand alone artifact to some repository with helm push. Here is my proposal #789

[dex4er]

@stefanprodan I think I don't understand. Currently, OCIRepository might be used as a source for Flux's Kustomization and it might contain all different types of files, not just Kubernetes manifests: Helm charts too. Is there any technical limitation as to why it can't be used by Kustomizations and not by HelmReleases? Especially, there is already GitRepository and it can be used as a source for HelmReleases already.

Additional context: I have a Helm charts with Karpenter's templates and provisioners. I don't need any versioning besides the "latest" tag. It is not a generic chart and each cluster (environment) uses a separate variant of the chart with the proper Karpenter's configuration. I think it will be the same with configs for cert-manager and Istio in future. The Helm charts are used because I need more advanced templating than provided by Kustomization (ie. base64 function). All I need is literally a single OCI artifact per cluster with multiple charts inside: as I already have single git repository for all Kustomizations too.