feat: support per-component Deployment labels and annotations - #882

@somaz94 Can chart templating support added to the values?
That is replace:

{{- toYaml . | nindent 4 }}

with

{{- tpl (toYaml .) $ | nindent 4 }}

Done in 024f997 — thanks for the suggestion! I switched the six deploymentLabels/deploymentAnnotations renders to {{- tpl (toYaml .) $ | nindent 4 }} across the operator, metrics-adapter, and webhooks Deployments, so values can now use template expressions (e.g. {{ .Release.Name }}).

I scoped the change to the new per-component fields only and left the existing additionalAnnotations render as-is to avoid changing its behavior. Verified locally:

• default render (fields unset) is byte-identical
• --set deploymentLabels.keda.release='{{ .Release.Name }}' resolves to release: keda
• helm lint clean

The single red leg (Deploy to Kubernetes v1.34 in 'not-keda') is an infra flake unrelated to this change. The post-install hook raced the admission webhook coming up:

Error: INSTALLATION FAILED: failed post-install: Hook post-install keda/templates/extensibility/extra-manifests.yaml failed:
... Kind=ClusterTriggerAuthentication: failed calling webhook "vsclustertriggerauthentication.kb.io":
dial tcp 10.96.49.71:443: connect: connection refused

The webhook Service wasn't accepting connections yet when the post-install hook applied the ClusterTriggerAuthentication. This PR only changes deploymentLabels/deploymentAnnotations rendering (now tpl-aware per @mindw's request) and doesn't touch the webhook or hook ordering; the same leg passes on re-run. @wozniakjan could you re-run just that failed job when you get a chance? Thanks!

@JorTurFer thanks for the approval on Aug 11 — checking in on what's left here.

CI is green and there are no outstanding review threads: @mindw's tpl suggestion was applied back in 024f997 (all six deploymentLabels / deploymentAnnotations renders across the operator, metrics-adapter and webhooks now go through {{- tpl (toYaml .) $ | nindent 4 }}).

GitHub still reports the PR as blocked, which I assume is a second approval or a merge window rather than anything on my side — but let me know if there's something I've missed and I'll get to it.

Thanks for taking a look @wozniakjan. Before I move these, can I check the premise with you? I think additionalAnnotations is a different axis rather than the same one.

There are two additionalAnnotations in the chart today and neither is per-component:

• the top-level one (values.yaml L304, "Custom annotations to add into metadata") is chart-wide — it lands on every resource
• crds.additionalAnnotations is scoped to a resource kind, not to a component

The operator: block you linked (L98–169) doesn't have one, so there isn't an existing per-component additionalAnnotations for these to be consistent with — putting them there would be establishing that convention rather than following it.

And the global one isn't in competition with this PR; the two already compose:

$ helm template keda ./keda \
    --set-string 'additionalAnnotations.global-one=yes' \
    --set-string 'deploymentAnnotations.keda.per-component=yes'
...
kind: Deployment
metadata:
  name: keda-operator
  annotations:
    global-one: "yes"
    per-component: "yes"

What I did mirror is podAnnotations / podLabels, which sit directly above these in values.yaml and are the exact analog one level down — same three components, same top-level map, pod metadata instead of deployment metadata:

podAnnotations:
  keda: {}
  metricsAdapter: {}
  webhooks: {}

deploymentAnnotations:   # this PR
  keda: {}
  metricsAdapter: {}
  webhooks: {}

One consequence worth weighing before you decide: the component blocks are operator: / metricsServer: / webhooks:, while these maps key on keda / metricsAdapter / webhooks. So operator.additionalAnnotations isn't only a move — it renames two of the three keys for users, and it would leave deployment annotations living somewhere different from the pod annotations right next to them.

Genuinely happy either way, it's your chart. If you'd still prefer the per-component blocks I'll restructure all six renders plus values.yaml and the README, and in that case I'd suggest moving podAnnotations/podLabels the same way later so the two don't drift apart. Just let me know which you'd like and I'll push it.