tool calls
[
{
"capability": "jira.issue.read",
"args": {
"key": "MZCLD-3843"
},
"result": {
"key": "MZCLD-3843",
"summary": "MozCloud Helm charts: envFromFields is silently ignored for Jobs and CronJobs",
"status": "Backlog",
"description_text": "Problem envFromFields (downward-API env vars rendered as valueFrom.fieldRef ) works for workload containers but is completely inert for Jobs and CronJobs . The key passes schema validation and is documented for task containers, so nothing warns and nothing fails \u2014 the env var simply never appears in the rendered pod spec. A tenant declaring it on a job container gets a container with no env at all, which is the same silent-drop failure mode as MZCLD-3725 (different root cause, already fixed). Reproduction Against the released mozcloud 3.11.0 artifact (unmodified, pulled from the registry), with the same envFromFields block applied to a workload, a job and a cron job: tasks:\n jobs:\n probe-job:\n type: preDeployment\n containers:\n job:\n image: {repository: test-repo/img, tag: \"1.0\"}\n command: [\"sh\", \"-c\"]\n args: [\"true\"]\n envFromFields:\n K8S_NAMESPACE: metadata.namespace\n cronJobs:\n probe-cronjob:\n schedule: \"0 0 * * *\"\n jobConfig:\n containers:\n job:\n image: {repository: test-repo/img, tag: \"1.0\"}\n command: [\"sh\", \"-c\"]\n args: [\"true\"]\n envFromFields:\n K8S_NAMESPACE: metadata.namespace\nworkloads:\n probe-workload:\n component: web\n containers:\n app:\n image: {repository: test-repo/img, tag: \"1.0\"}\n envFromFields:\n K8S_NAMESPACE: metadata.namespace helm template succeeds with no warning, and the rendered containers are: Deployment probe-workload container=app env=['K8S_NAMESPACE']\nJob probe-job container=job env=NONE\nCronJob probe-cronjob container=job env=NONE Impact \u2014 one tenant is affected today The orchestrator tenant's llm-visibility chart sets this on its pre-deployment migration job \u2014 values.yaml#L208-L210 \u2014 and uses the identical two-line block on its three workload containers. Rendered with the lib version the tenant actually pins ( 3.4.0 ) and its prod values: Deployment llm-visibility container llm-visibility \u2192 K8S_NAMESPACE , K8S_POD_NAME present Deployment llm-visibility-worker containers scheduler and worker \u2192 both present Job llm-visibility-db-migrate \u2192 env: None , both dropped Whether that actually hurts depends on what the migrate job does with those two variables (they look like logging/OTEL resource attributes) \u2014 worth a word with the owning team rather than assuming breakage. The point for this ticket is that declared configuration is silently discarded. Root cause The task template never implements the feature. Compare the two env blocks on main ( a314a0f , = released 3.11.0): Workloads \u2014 workload/_helpers.tpl#L153 includes $containerConfig.envFromFields in the env: gate, and #L162-L167 ranges over it and emits the fieldRef entries. Tasks \u2014 task/_jobTemplate.yaml#L118 gates only on envVars and the OTEL HOST_IP case, and there is no envFromFields range anywhere in the file. CronJobs inherit the same gap because task/cronjob.yaml includes the same mozcloud.job.jobTemplate for its jobTemplate.spec . Why it looks supported envFromFields lives in $defs/container , which is what tasks.common.container references \u2014 so task values validate cleanly. It is documented only in the tasks section of values.yaml#L539-L548 \u2014 i.e. exactly where it does not work. The root-cause analysis in MZCLD-3725 also lists envFromFields among the keys tasks.jobs.default.containers.default declares, treating it as a supported job container key. Proposed fix Add $containerConfig.envFromFields to the env: gate in task/_jobTemplate.yaml and add the matching range block, mirroring the workload helper. Roughly six lines, and it fixes Jobs and CronJobs in one go. Extend the existing tests/env-from-fields-configuration_test.yaml suite, which today only renders workload/deployment.yaml , to cover a Job and a CronJob as well. The missing coverage is why this went unnoticed. Second, smaller part \u2014 the mirror-image documentation gap: workload containers do support envFromFields , but it is not documented at the workload or init-container sites in values.yaml . Add it there so the docs and the implementation agree in both directions. Acceptance criteria A job container with envFromFields renders the corresponding valueFrom.fieldRef env entries. The same holds for cron job containers. It composes with envVars and with the OTEL HOST_IP entry rather than replacing them, and works when set via tasks.common.container . A container without the key renders no env entries from this feature, and every pre-existing snapshot is unchanged. llm-visibility's migration job picks up its two variables after the tenant bumps the lib. Found while implementing MZCLD-3646 . It is unrelated to and pre-dates that change \u2014 the reproduction above is against the unmodified released 3.11.0 artifact.",
"comment_count": 0,
"comments": []
}
}
]