[artifactory] rtfs-deployment.yaml lacks values knob for pod template labels

[bmanuel]

Is this a request for help?:

No.

---

Is this a BUG REPORT or FEATURE REQUEST? (choose one):

Feature request.

Version of Helm and Kubernetes:

Chart-side issue, reproducible against any recent Helm/Kubernetes. Verified rendering with Helm 3.15+ and the chart at versions below.

Which chart:

artifactory (verified at version 107.146.8). The jfrog-platform umbrella chart bundles this same template via its artifactory subchart, so consumers of jfrog-platform 11.5.1 hit the same gap.

Which product license (Enterprise/Pro/oss):

N/A — chart template surface; applies regardless of license.

JFrog support reference (if already raised with support team):

None.

What happened:

templates/rtfs/rtfs-deployment.yaml does not expose a values knob for adding custom labels to the Pod template (spec.template.metadata.labels).

Three knobs related to RTFS labels/annotations are exposed today:

• rtfs.deployment.labels → Deployment metadata.labels
• rtfs.deployment.annotations → Deployment metadata.annotations
• rtfs.annotations → pod template spec.template.metadata.annotations

There is no equivalent for pod template spec.template.metadata.labels. The pod template label set is hardcoded:

# templates/rtfs/rtfs-deployment.yaml (~lines 50–55 in 107.146.8)
template:
  metadata:
    labels:
      app: {{ template "artifactory.name" . }}
      chart: {{ template "artifactory.chart" . }}
      component: {{ .Values.rtfs.name }}
      heritage: {{ .Release.Service }}
      release: {{ .Release.Name }}

By contrast, templates/artifactory-statefulset.yaml exposes a single .Values.artifactory.labels knob that is applied to both the StatefulSet metadata.labels and the pod template spec.template.metadata.labels. That is the consistent pattern across the chart for other workloads. RTFS appears to be an outlier.

What you expected to happen:

A values knob that injects custom pod template labels for the RTFS Deployment, consistent with how artifactory.labels works for artifactory-statefulset.yaml. Any of the following would resolve the gap (preferred order):

1. Add a single rtfs.labels value applied to both Deployment.metadata.labels and Deployment.spec.template.metadata.labels, mirroring the existing artifactory.labels pattern.
2. Add a new rtfs.podLabels (or rtfs.template.labels) value scoped specifically to the pod template, leaving rtfs.deployment.labels unchanged for the Deployment-level labels.

Option (1) is the smallest delta and matches the existing chart convention.

How to reproduce it (as minimally and precisely as possible):

1. Render the chart with RTFS enabled and a custom label set on rtfs.deployment.labels:

   helm template my-release jfrog/artifactory --version 107.146.8 \
     --set rtfs.enabled=true \
     --set rtfs.deployment.labels.foo=bar \
     | grep -A 30 'name: my-release-artifactory-rtfs$'

2. Observe: the Deployment's metadata.labels contains foo: bar, but the pod template's spec.template.metadata.labels only contains the hardcoded app/chart/component/heritage/release labels.

Anything else we need to know:

The motivating use case is admission-control policies (e.g., Kyverno, OPA Gatekeeper, validating webhooks) that require organization-mandated labels on pod templates — team, tier, cost-center, etc. Without a values knob, operators have to either:

• Apply a post-render kustomize step outside the chart (kustomize labels: with includeSelectors: false works but introduces a separate moving piece), or
• Maintain a local fork of rtfs-deployment.yaml.

Both add friction on chart upgrades. A single new values knob, consistent with the rest of the chart, would resolve this with minimal change.