OCI HelmRepository leaves status empty (Ready printer column blank) even when HelmCharts pull successfully

[RaviTharuma]

Describe the bug

OCI HelmRepository objects leave status: {} entirely empty after reconcile, so kubectl printer columns for Ready and Status are blank. Operators cannot tell “OCI repo is fine (no index to fetch)” from “never reconciled / broken.”

On the same cluster, HTTP(S) HelmRepositories populate status.artifact and report Ready=True as expected. Downstream HelmCharts that reference the empty-status OCI HelmRepositories still pull charts successfully (Ready=True, version present). So the pipeline works — only the parent OCI HelmRepository status is unusable for operations.

The CRD additionalPrinterColumns for Ready resolve:

.status.conditions[?(@.type=="Ready")].status

When there are no conditions, kubectl get helmrepository shows blank Ready/Status for every type: oci object. That is the day-to-day UX failure: inventory dashboards and quick kubectl get triage treat OCI repos as “maybe dead” even when chart pulls succeed.

Steps to reproduce

1. Install Flux with helm/source controllers (observed on source-controller v1.9.2, distribution flux-v2.9.1, CLI v2.9.4).
2. Apply an OCI HelmRepository, for example:

apiVersion: source.toolkit.fluxcd.io/v1
kind: HelmRepository
metadata:
  name: example-oci
  namespace: flux-system
spec:
  type: oci
  provider: generic
  interval: 1h
  url: oci://ghcr.io/<org>/charts

3. Apply a HelmChart (or HelmRelease that creates one) that pulls a chart from that repository.
4. Observe:

kubectl get helmrepository -A
# type=oci rows: Ready and Status columns empty

kubectl get helmrepository example-oci -n flux-system -o yaml
# status: {}

5. Compare with an HTTP HelmRepository on the same cluster: Ready=True, artifact sha256 present.
6. Confirm the dependent HelmChart is Ready=True with a pulled version — chart consumption works despite empty parent status.

Expected behavior

Operators need a clear, machine-readable signal that an OCI HelmRepository is healthy (or intentionally has no index artifact), distinct from “controller never touched this object.”

Concrete options (any of these would help):

1. Preferred: After validating the OCI URL / credentials / reachability, set Ready=True with a reason such as OCIRepository or NoIndex (message: OCI HelmRepositories do not produce an index artifact; charts are resolved on demand).
2. Docs + UX: Document that empty status for type: oci is expected, and add a printer column (or condition) that surfaces type=oci / “index N/A” so blank Ready is not the only signal.
3. Optional: When a dependent HelmChart successfully pulls from the repo, reflect something like last successful chart resolution on the HelmRepository (even if not a full artifact).

Not asking for OCI repos to fake an HTTP-style index artifact if that is architecturally wrong — asking for status parity for operations.

Environment

• Kubernetes: single-node (generic)
• Flux CLI: v2.9.4
• In-cluster distribution: flux-v2.9.1
• source-controller: v1.9.2
• helm-controller: v1.6.2
• Mix of HTTP HelmRepositories (Ready=True, artifact present) and OCI HelmRepositories (status: {})
• Downstream HelmCharts from OCI repos: Ready=True, chart version pulled successfully

Additional context

• Area: OCI / HelmRepository
• Related operational pain: Alert / monitoring on HelmRepository Ready is useless for OCI when conditions never exist.
• Companion docs request will be filed against fluxcd/website so operators know how to verify OCI sources today (check HelmChart / HelmRelease, not only kubectl get helmrepository).

Code of Conduct

• I agree to follow this project's Code of Conduct

[RaviTharuma]

Docs companion: fluxcd/website#2643 (how to verify OCI HelmRepository when Ready is blank).