[Feature Request] Add Kubernetes status.conditions (Ready/Progressing/Degraded) for TemporalConnection and TemporalWorkerDeployment for Argo CD health

[isarns]

Is your feature request related to a problem? Please describe.

We deploy Temporal Worker Controller CRDs via Argo CD. Argo CD can’t reliably determine when these resources are “Healthy/Ready”, so Applications assume those are healthy and we can’t gate sync waves or use kubectl wait.

Current issues:

• TemporalConnection effectively has no readiness signal (no meaningful status), so Argo CD can’t tell if the connection is usable.
• TemporalWorkerDeployment has rollout info under status.targetVersion/currentVersion, but no standard status.conditions[] that GitOps tooling can consume.

Example TemporalWorkerDeployment status we see:

status:
  targetVersion:
    buildID: tag-c5fb
    deployment:
      apiVersion: apps/v1
      kind: Deployment
      name: my-deploy-tag-c5fb
      namespace: namespace_here
      uid: UUID4
    healthySince: '2026-02-12T07:15:09Z'
    status: NotRegistered

From Argo CD perspective, this is not a canonical “ready” signal, so we either accept Unknown health or write brittle custom Lua health checks that parse controller-specific fields.

Describe the solution you'd like

Add standard Kubernetes Conditions to both CRDs so Argo CD (and kubectl/CI) can reason about readiness consistently.

TemporalConnection

Add:

• status.conditions: []metav1.Condition
• (recommended) status.observedGeneration

Semantics:

• Ready=True when the controller can successfully establish/authenticate a Temporal client using this connection.

• Ready=False with clear reason/message when:

  • referenced Secret missing/invalid
  • TLS config invalid
  • auth fails
  • dial/connect fails

TemporalWorkerDeployment

Add:

• status.conditions: []metav1.Condition
• (recommended) status.observedGeneration

Minimal condition set:

• Ready: True when an effective “current” version is registered in Temporal AND the backing K8s Deployment is healthy.
• Progressing: True while rollout is in-flight (target exists but not yet current / ramping / waiting on pollers / waiting on Deployment health).
• Degraded: True on reconcile errors that block progress.

Suggested mappings (examples):

• targetVersion.status=NotRegistered -> Progressing=True, Ready=False, reason WaitingForPollers
• backing Deployment not healthy / healthySince unset -> Progressing=True, reason WaitingForDeployment
• currentVersion.status=Current AND backing Deployment healthy -> Ready=True, Progressing=False

This enables:

• kubectl wait --for=condition=Ready temporalconnection/<name>
• kubectl wait --for=condition=Ready temporalworkerdeployment/<name>
• simple Argo CD health checks based only on status.conditions (stable API surface)

(Optional) Add kubebuilder printcolumns for READY + CURRENT/TARGET build IDs to improve kubectl get UX.

Additional context

Argo CD supports custom health checks for CRDs, but they work best when controllers expose conventional status.conditions[]. This mirrors patterns used by other controllers (e.g., Crossplane resources) to integrate cleanly with Argo CD health assessment.