Yassin Kortam 4f7f706a63 fix(helm): truncate the helm.sh/chart label to 63 bytes ... Kubernetes caps a label value at 63 bytes and .Chart.Version is unbounded. CI publishes branch builds as 0.0.0-branch-<branch>-<sha>, so helm.sh/chart rendered as a 64 byte value and the API server rejected every labeled resource with "must be no more than 63 bytes", including the migrations Job. The litellm-helm chart already guards this through a litellm.chart helper; this adds the same helper here. Swept the rest of the chart for label and name values built from unbounded input. .Chart.Version appeared only in this label. The remaining candidates all derive from .Release.Name, which helm itself caps at 53 characters, so they cannot overflow; three of them are selector labels feeding immutable Deployment matchLabels, where adding trunc would risk churn for no gain. They are left alone deliberately. Verified with a new helm-unittest suite, tests/chart_label_tests.yaml, which overrides chart.version per test: helm unittest -f 'tests/*.yaml' helm/litellm # 13 passed helm unittest -f 'tests/*.yaml' helm/litellm-helm # 54 passed The truncation cases fail against the previous helper. Reproduced the original overflow by rendering with the real branch version and measuring the label: helm template rel helm/litellm -f helm/litellm/tests/values/required.yaml \ | grep helm.sh/chart # 64 bytes before, 63 after		2026-07-09 19:38:16 +03:00
..
litellm	fix(helm): truncate the helm.sh/chart label to 63 bytes	2026-07-09 19:38:16 +03:00
litellm-helm	refactor(helm): move litellm-helm chart to helm/ and drop deploy folder (#32234)	2026-07-07 15:18:33 +03:00