feat(helm): support tpl rendering in podAnnotations

[devauxbr]

Closes #28332

Summary

Render Values.podAnnotations through tpl ... $ in deploy/charts/litellm-helm/templates/deployment.yaml, so users can include template expressions (e.g. a sha256 of their custom ConfigMap) inside pod annotations.

 {{- with .Values.podAnnotations }}
-{{- toYaml . | nindent 8 }}
+{{- tpl (toYaml .) $ | nindent 8 }}
 {{- end }}

Motivation

When users disable proxyConfigMap.create to provide their own ConfigMap, the chart's built-in checksum/config annotation is also disabled, so changes to a user-managed ConfigMap no longer roll the deployment. Allowing tpl in podAnnotations lets users re-implement that annotation themselves, e.g.:

podAnnotations:
  checksum/config: '{{ include "my-umbrella.litellm-config" . | sha256sum }}'

Consistency with existing chart code

This matches the tpl (toYaml .) $ pattern already used elsewhere in the same chart:

• deploy/charts/litellm-helm/templates/deployment.yaml:50 — extraInitContainers
• deploy/charts/litellm-helm/templates/deployment.yaml:215 — extraContainers
• deploy/charts/litellm-helm/templates/migrations-job.yaml:40,99 — migrations job

Direct precedent: commit 87d7e86479 ("feat(helm): add tpl support to extraContainers and extraInitContainers", April 2026).

Tests

Added one new helm unittest case to deploy/charts/litellm-helm/tests/deployment_tests.yaml:

• should support tpl in podAnnotations — sets proxyConfigMap.create: false to mirror the real-world scenario, then asserts that a templated annotation referencing .Values.image.tag resolves correctly (proves $ is wired), a second key referencing .Values.image.repository resolves correctly, and a plain-string annotation passes through unchanged (backward-compat canary).

Run locally with make test-unit-helm — all 54 tests pass.

Also manually verified with helm template that .Release.Name and | sha256sum pipelines resolve correctly inside annotations.

Backward compatibility

tpl passes plain strings (no {{ }}) through unchanged, so existing chart users see no behavior change. Users with a literal {{ inside an annotation value would now see it rendered as a template — that caveat already applies to every other tpl usage in this chart, and to the precedent PR above.

Checklist

• Sign the Contributor License Agreement (CLA)
• Keep scope isolated — one helm-only one-liner + one test
• Helm unit test added — make test-unit-helm passes
• helm lint deploy/charts/litellm-helm passes

[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.}

[greptile-apps]

Greptile Summary

This PR pipes podAnnotations through tpl (toYaml .) $ in deployment.yaml, allowing users to embed Helm template expressions (e.g. sha256sum of a custom ConfigMap) inside annotation values. It mirrors the identical pattern already used for extraInitContainers and extraContainers in the same file.

• deployment.yaml: Single-line change swaps toYaml . | nindent 8 for tpl (toYaml .) $ | nindent 8 inside the {{- with .Values.podAnnotations }} block.
• deployment_tests.yaml: New helm unittest case validates that two {{ .Values.* }} expressions resolve correctly and that a plain-string annotation is passed through unchanged, covering backward compatibility.

Confidence Score: 5/5

Safe to merge — the change is a focused one-liner that follows an established pattern already present in the same file and chart.

The change is minimal and its behavior is well-understood: tpl passes plain strings unchanged, so existing users are unaffected. The templating caveat (literal {{ in annotation values now renders) is already documented in the PR description and identical to every other tpl call in this chart. The new unit test covers the primary use-case and the backward-compat path. No logic outside the Helm layer is touched.

No files require special attention.

Important Files Changed

Filename	Overview
deploy/charts/litellm-helm/templates/deployment.yaml	One-line change wraps podAnnotations serialization through tpl (toYaml .) $, consistent with existing extraInitContainers/extraContainers usage in the same file.
deploy/charts/litellm-helm/tests/deployment_tests.yaml	New test case verifies tpl rendering of two distinct {{ .Values.* }} expressions and confirms plain-string annotations pass through unchanged (backward-compat canary).

_{Reviews (1): Last reviewed commit: "feat(helm): support tpl rendering in pod..." | Re-trigger Greptile}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[oss-pr-review-agent-shin]

🤖 litellm-agent: Auto-merge skipped — the staging branch shin_agent_oss_staging_05_20_2026 has 8 commit(s) not in your branch. Merging as-is would produce a confusing diff on the staging PR.

Please rebase your branch onto shin_agent_oss_staging_05_20_2026 and push; the agent will re-review automatically.

[veria-ai]

PR overview

Medium: Pod annotations now execute Helm templates

This PR changes podAnnotations from data rendering to Helm template evaluation. Anyone who can influence this values field can now run Helm template functions such as lookup during render and write the result into pod annotations.

Security review

• 1 new security issue(s) were flagged in the latest review.
• 1 issue(s) remain open on this pull request.

Risk: 5/10

[veria-ai]

Medium: Helm template execution in annotations

tpl evaluates annotation values as Helm templates, so a values author can set an annotation like {{ (lookup "v1" "Secret" "default" "some-secret").data.token }} and have Helm copy data readable by the release credentials into the rendered pod annotations. If this field is intended to be safe for less-trusted values input, keep it as plain YAML rendering or gate template evaluation behind a clearly separate opt-in value.