[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 https://github.com/fluxcd/helm-controller/issues/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.

[artem-nefedov]

I am very confused about the design decision to allow Bucket and GitRepository but not OCIRepository to be specified in sourceRef of a HelmRelease, despite all of them being served equally as a .tar.gz archive by the source-controller.

We wanted to use OCI artifact that contains other things besides helm chart inside (which is why chartRef doesn't work), and specify path via spec.chart.spec.chart. That worked without problems with Bucket, but apparently it's not possible with OCIRepository, with no real technical reason for this limitation.

[matheuscscp]

Use spec.chartRef

spec.chart is bad, don't use it

Edit: Sorry, read your post too fast. You need to build a proper helm OCI artifact with helm push oci://

[artem-nefedov]

Edit: Sorry, read your post too fast. You need to build a proper helm OCI artifact with helm push oci://

The whole point of my post is that there's a situation where I can't/don't want to build a separate artifact and helm push it to registry, instead option for applying the chart from the filesystem. And since it's already supported for Bucket and GitRepository, I don't see any reason why it can't be allowed for OCIRepository as well.

[matheuscscp]

Yeah, I wouldn't opposite too much. Need to see what other maintainers have to say, though, maybe there's a strong reason for not supporting OCIRepository in the HelmChart API spec.sourceRef that I'm not aware of.

In any case, are you willing to contribute this feature? If other maintainers agree, I think it's not a big change, we just need to add OCIRepository here:

https://github.com/fluxcd/source-controller/blob/9dedcede9d47d925caea7251e8ad073c5bb93dc1/api/v1/helmchart_types.go#L106-L108

And here:

https://github.com/fluxcd/source-controller/blob/9dedcede9d47d925caea7251e8ad073c5bb93dc1/internal/controller/helmchart_controller.go#L909

And here:

https://github.com/fluxcd/source-controller/blob/9dedcede9d47d925caea7251e8ad073c5bb93dc1/internal/controller/helmchart_controller.go#L502

And add some tests and docs.

[matheuscscp]

Actually here as well:

https://github.com/fluxcd/source-controller/blob/9dedcede9d47d925caea7251e8ad073c5bb93dc1/internal/controller/helmchart_controller.go#L178-L200

And here:

https://github.com/fluxcd/source-controller/blob/9dedcede9d47d925caea7251e8ad073c5bb93dc1/internal/controller/helmchart_controller.go#L772

And one of these:

https://github.com/fluxcd/source-controller/blob/9dedcede9d47d925caea7251e8ad073c5bb93dc1/internal/controller/helmchart_controller.go#L1165-L1193

lol might find a few other places while implementing but should be easy

[artem-nefedov]

I could try if it's confirmed that there are no objections on design side

[amferguson]

Any update / progress? This same use case led me to this issue when I (incorrectly) assumed that OCIRepository was on equal footing with the Bucket and GitRepository options with regard to sourceRef.

I don't have anything else to add that hasn't already been mentioned by @dex4er or @artem-nefedov, but we're in a similar spot in terms of the HelmRelease being a convenient way to deploy things as a single unit, but not something really intended to be reusable outside of any given cluster, nor necessary to version separately, since it would sit alongside the Kustomizations in the OCI artifact.

Thanks!

[matheuscscp]

Let's hear other maintainers, as I said I don't like the idea since we already have a main way to support OCI Helm repositories, the one defined by Helm itself, but I wouldn't stand too much in the way of this feature either if a decent PR showed up.

[stefanprodan]

This can now be achieved with Flux 2.7 using source-watcher :

Example:

apiVersion: source.extensions.fluxcd.io/v1beta1
kind: ArtifactGenerator
metadata:
  name: podinfo
  namespace: apps
spec:
  sources:
    - alias: monorepo
      kind: OCIRepository
      name: my-monorepo
  artifacts:
    - name: podinfo-chart
      copy:
        - from: "@monorepo/charts/podinfo/**"
          to: "@artifact/podinfo/"
---
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: podinfo
  namespace: apps
spec:
  interval: 15m
  releaseName: podinfo
  chartRef:
    kind: ExternalArtifact
    name: podinfo-chart