Problem
Cloud Run job workflows fail before deployment because render_backend_runtime_env.py eagerly renders every service and job in the selected environment, including unrelated required env_var entries that the job workflow neither provides nor consumes.
Main run 29360853200 demonstrates the failure in gcp_memory_maintenance_job_auto_dev.yml:
ValueError: GOOGLE_CLIENT_ID requires $GOOGLE_CLIENT_ID to be set
GOOGLE_CLIENT_ID belongs to backend service runtime metadata, not the memory-maintenance job. The workflow only consumes cloud_run_flags and memory_maintenance_job_* outputs, but rendering aborts while visiting an unrelated service before those job outputs are emitted. The manual memory-maintenance and notifications job workflows have the same coupling.
Proposed contract
Add an explicit --job <name> selector to the renderer:
- With no selector, retain the existing full-environment output used by backend service deployments.
- With
--job, validate and render network flags plus only the named job outputs.
- Reject unknown job names before emitting a partial target configuration.
Wire both memory-maintenance workflows to --job memory-maintenance-job and the notifications workflow to --job notifications-job.
Acceptance criteria
- Rendering a selected job succeeds without unrelated service-only environment variables.
- Required variables for the selected job and shared network flags remain fail-closed.
- Full-environment renderer behavior remains unchanged when
--job is omitted.
- Unknown jobs fail clearly.
- Focused renderer, workflow-contract, runtime-env validation, actionlint, and pre-push checks pass.
Problem
Cloud Run job workflows fail before deployment because
render_backend_runtime_env.pyeagerly renders every service and job in the selected environment, including unrelated requiredenv_varentries that the job workflow neither provides nor consumes.Main run 29360853200 demonstrates the failure in
gcp_memory_maintenance_job_auto_dev.yml:GOOGLE_CLIENT_IDbelongs to backend service runtime metadata, not the memory-maintenance job. The workflow only consumescloud_run_flagsandmemory_maintenance_job_*outputs, but rendering aborts while visiting an unrelated service before those job outputs are emitted. The manual memory-maintenance and notifications job workflows have the same coupling.Proposed contract
Add an explicit
--job <name>selector to the renderer:--job, validate and render network flags plus only the named job outputs.Wire both memory-maintenance workflows to
--job memory-maintenance-joband the notifications workflow to--job notifications-job.Acceptance criteria
--jobis omitted.