[helm][kuberay-operator] Don't emit empty ServiceMonitor labels; rename selector -> additionalLabels

[kevin85421]

Why are these changes needed?

Two fixes to helm-chart/kuberay-operator/templates/servicemonitor.yaml:

1. Don't emit an empty labels: block

The template unconditionally rendered a labels: key:

  labels:
    {{- with .Values.metrics.serviceMonitor.selector }}
      {{- toYaml . | nindent 4 }}
    {{- end }}

With the default (empty) value, this produced an empty metadata.labels, which doesn't match what Kubernetes actually stores on the object. As a result ArgoCD reports the ServiceMonitor as OutOfSync. The labels: key is now wrapped in {{- with }} so it's only emitted when labels are actually configured.

2. Rename selector → additionalLabels

.Values.metrics.serviceMonitor.selector populates the ServiceMonitor's metadata.labels — it is not a selector. The name was confusing because:

• It sets labels, not a selector.
• It collided conceptually with the template's real spec.selector (which selects the Service to scrape).

The value exists so that Prometheus can discover this ServiceMonitor via its serviceMonitorSelector (e.g. release: prometheus for kube-prometheus-stack). additionalLabels matches the convention used by other charts (e.g. kube-prometheus-stack) and describes what the field actually does.

Warning

Breaking change: users setting metrics.serviceMonitor.selector must switch to metrics.serviceMonitor.additionalLabels. Happy to instead keep selector as a deprecated fallback for one release if reviewers prefer a non-breaking path.

Related issue number

Checks

values.yaml and the helm-docs-generated README.md row were updated to match. Verified with helm lint (passes) and helm template:

• ServiceMonitor enabled, no additionalLabels → no labels: key rendered.
• ServiceMonitor enabled, additionalLabels.release=prometheus → metadata.labels.release: prometheus rendered.

🤖 Generated with Claude Code

[Future-Outlier]

LGTM