feat(wrt): auto-inject KEDA Temporal trigger metadata for per-version ScaledObjects

[nikoul]

Summary

Extends WorkerResourceTemplate auto-injection to populate the workerDeploymentName and workerDeploymentBuildId fields in KEDA ScaledObject triggers[*].metadata when the trigger type is "temporal". This unblocks using KEDA's Temporal scaler (kedacore/keda#7672) as the templated resource for per-version backlog scaling, as requested in #286.

Closes (or contributes towards) #286.

Motivation

For users who already run KEDA cluster-wide for non-Temporal workloads, KEDA owns the external.metrics.k8s.io APIService — only one external metrics provider can be installed per cluster. That makes the documented WRT-HPA + prometheus-adapter path unavailable: prometheus-adapter cannot co-exist with KEDA on the same APIService.

KEDA's recent Worker Deployment Versioning support (kedacore/keda#7672) makes it possible for a KEDA ScaledObject to scale a single worker version by querying Temporal Cloud directly with workerDeploymentName + workerDeploymentBuildId. WRT already supports templating arbitrary kinds (verified: spec.template is unstructured, SSA-applied, with a kind allow-list in the chart) and scaleTargetRef: {} auto-fill works recursively. The only missing piece was injecting the per-version identifiers into the KEDA trigger metadata — same source values the controller already injects into HPA External metric selectors, different JSON path.

Behaviour

For each templated resource that contains:

spec:
  triggers:
    - type: temporal
      metadata:
        workerDeploymentName: ""        # placeholder, any string value
        workerDeploymentBuildId: ""     # placeholder, any string value
        # ...other user-provided KEDA Temporal scaler metadata

the controller sets:

• workerDeploymentName ← wrt.Spec.EffectiveWorkerDeploymentName()
• workerDeploymentBuildId ← the per-version build ID

Injection is opt-in: the keys are only touched if already present in the template's metadata map (mirroring the existing metrics[*].external.metric.selector.matchLabels merge pattern). Non-temporal triggers in the same ScaledObject are left untouched.

Example

apiVersion: temporal.io/v1alpha1
kind: WorkerResourceTemplate
metadata:
  name: my-worker-scaler
  namespace: default
spec:
  workerDeploymentRef:
    name: my-worker
  template:
    apiVersion: keda.sh/v1alpha1
    kind: ScaledObject
    spec:
      scaleTargetRef: {}                     # auto-injected (versioned Deployment)
      minReplicaCount: 1
      maxReplicaCount: 10
      pollingInterval: 30
      triggers:
        - type: temporal
          metadata:
            endpoint: us-east-1.aws.api.temporal.io:7233
            namespace: my-temporal-ns
            taskQueue: my-task-queue
            workerDeploymentName: ""         # auto-injected
            workerDeploymentBuildId: ""      # auto-injected
            targetQueueSize: "10"
          authenticationRef:
            kind: ClusterTriggerAuthentication
            name: temporal-cloud-auth

The controller will stamp one ScaledObject per active worker version, each with the correct workerDeploymentBuildId, and delete them on sunset via the existing DeleteWorkerResources planner (kind-agnostic).

Implementation

• appendTemporalTriggerMetadata(spec, twdName, buildID) — new helper that walks spec.triggers[*], filters on type == "temporal", and sets the two keys if already present.
• autoInjectFields signature now takes twdName, buildID so it can pass them through. Behaviour for HPA / matchLabels / scaleTargetRef is unchanged.

Helm-side: adding ScaledObject to workerResourceTemplate.allowedResources + the controller's ClusterRole is left as a follow-up (or a separate commit in this PR if maintainers prefer). For users who want this today, they can add the entry to their chart values without further controller changes.

Tests

New TestAutoInjectFields_TemporalTriggerMetadata covers:

• injects when both keys present (empty string placeholders)
• overwrites stale values
• no-op when keys absent (opt-in semantics)
• non-temporal triggers are untouched (heterogeneous trigger array)
• scaleTargetRef: {} auto-fill still works on ScaledObject
• no panic when spec.triggers is absent

All existing tests still pass (go test ./...).

[CLAassistant]

All committers have signed the CLA.

[carlydf]

I think this is valid, but just an idea, in preparation for the auto-injection of spec.metrics[*].external.metric.selector.matchLabels, the WorkerResourceTemplate validating webhook rejects objects that have the fields set, to avoid confusion and be very explicit where the fields are coming from. I think it would be consistent to do KEDA templating similarly. See https://github.com/temporalio/temporal-worker-controller/blob/main/docs/worker-resource-templates.md#auto-injection for existing semantics.

[carlydf]

Also, it would be most consistent if the controller templates the namespace field in the Temporal trigger too. The idea being, we know the Temporal namespace that the Worker Deployment is in, so no need for the user to mis-configure it.

[nikoul]

Thanks, I think I've implemented something that answers both those suggestions now.