Support per-build ConfigMaps generated from WorkerResourceTemplate and consumable by versioned worker Deployments

Hello,

I would like to propose support for creating a ConfigMap per active worker version/build ID, with the same lifecycle as the versioned Kubernetes Deployment managed by a TemporalWorkerDeployment.

Problem

Today, WorkerResourceTemplate is a good fit for per-version auxiliary resources such as HPAs and PDBs, but it is difficult to use it for configuration that must be consumed by the worker pod itself.

A common use case is:

• render one ConfigMap per active worker version
• populate it with configuration associated with that deploy/version
• mount or reference that ConfigMap from the corresponding versioned worker Deployment
• delete it automatically when that version is sunset and its Deployment is deleted

The main gaps are:

• there is no first-class way to generate a per-version ConfigMap from a concrete values source
• there is no convenient way for the pod template in TemporalWorkerDeployment to reference the generated per-version ConfigMap
• lifecycle alignment is important: the generated ConfigMap should be created, updated, and deleted together with the worker version that uses it

Proposed behavior

I would like to contribute support for the following flow:

1. A WorkerResourceTemplate can define a ConfigMap template.
2. The controller renders one ConfigMap per active Build ID, just like it already does for other WRT-managed resources.
3. The rendered ConfigMap can be populated from a specific values file/key stored in another ConfigMap (or similar explicit source).
4. The versioned worker Deployment can reference the generated ConfigMap through a stable controller-resolved placeholder/mechanism.
5. When the versioned worker Deployment is sunset, the rendered ConfigMap is deleted in the same cleanup flow.

Why this is useful

This would make it possible to keep version-specific runtime config close to the worker version lifecycle, without requiring users to manually create and clean up separate config objects for each rollout.

Example use cases:

• Helm/values-style config rendered per worker version
• feature flags or rollout parameters tied to a specific build
• generated config consumed as mounted files or env-from ConfigMap

Scope

My intention is to keep this narrowly scoped to per-version ConfigMap generation and consumption, reusing the existing WorkerResourceTemplate reconciliation and cleanup model as much as possible.

If this direction sounds reasonable, I can open a PR with a concrete proposal and implementation.

Thanks.

Start by tracing the existing WorkerResourceTemplate reconciliation and cleanup flow for versioned worker Deployments. Define how a per-Build-ID ConfigMap is rendered, populated from an explicit source, and referenced by the corresponding Deployment. Done means creation, updates, pod consumption, and deletion remain aligned with the worker version lifecycle.