[paulhobbel]

What was changed

Adds spec.deploymentLabels to WorkerDeployment. The controller copies these labels onto the metadata of each versioned Deployment it creates.

spec:
  deploymentLabels:
    team: payments
    example.com/instrumentation: "false"

• Selector labels always win: they are merged last, and a CEL rule on the field rejects temporal.io/build-id and temporal.io/deployment-name.
• Changes are applied in place to the Deployments of every version the controller manages (Target, Current and Draining), in the same write as the rolling-update strategy sync. No new Build ID is created and pods don't restart. The controller records the keys it applied in the temporal.io/managed-deployment-labels annotation, so removing a key from deploymentLabels removes it from the Deployments, while labels added by other tools are kept.
• The validating webhook checks label keys and values, so an invalid label is rejected at admission instead of stalling the rollout.

Why?

Today the generated Deployment only carries temporal.io/build-id and temporal.io/deployment-name. Labels in the pod template reach the pods, but tools that act on the Deployment object itself never see them. The case we hit: an admission webhook that opts workloads out by a label on the Deployment. It couldn't see the opt-out, so it instrumented the versioned Deployments and rewrote their pod template.

I chose an explicit field over copying the WorkerDeployment's own metadata.labels. Those often carry GitOps tracking labels (e.g. Argo CD's app.kubernetes.io/instance) or kustomize commonLabels. Copying them would make controller-owned Deployments look like resources managed by the GitOps tool, which can then report them as out of sync or prune them.

Checklist

1. Closes [Feature Request] Support custom labels on generated Kubernetes Deployment resources #187

2. How was this tested:

   • Unit tests for ApplyDeploymentLabels: adding labels to existing Deployments, changing and removing keys, keeping labels from other tools, never touching selector labels, and no change when in sync.
   • Planner test: label changes are queued for existing Deployments, including one already queued by a connection change, and nothing is queued once in sync.
   • Webhook tests: invalid label keys and values are rejected.
   • Unit test for NewDeploymentWithOwnerRef: labels land on the Deployment, not on the pods or the selector, and selector keys win on conflict.
   • envtest CEL specs: custom labels are accepted, and both reserved keys are rejected.
   • make generate manifests, make test-unit and make lint-code pass locally.

3. Any docs updates needed?
   Added a "Labels on versioned Deployments" section to docs/configuration.md.

🤖 Generated with Claude Code

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[jaypipes]

I like it. Thank you @paulhobbel! I'm targeting this for the v1.14.0 release (end of October), just FYI.

[jaypipes]

@paulhobbel You'll need to rebase to main in order to fix the failed e2e tests.

[tomba7]

Thanks for putting this together, @paulhobbel!

[paulhobbel]

Hi all, will update this PR today

[jaypipes]

One small bug I think I've uncovered @paulhobbel but overall this is great, thank you so much for this PR!

[jaypipes]

Great stuff @paulhobbel thank you!

[paulhobbel]

Hi @jaypipes it looks like I still need to accept the license. However, I already did and if I try to accept again it gives me an error

[jaypipes]

Hi @jaypipes it looks like I still need to accept the license. However, I already did and if I try to accept again it gives me an error

Nah, it's just a flaky issue with the CLA assistant thing :) I'll update the branch to main HEAD which should (hopefully) kick the CLA job into action...