Follow-up review of the metadata validation surfaced four gaps:
Listener pod metadata took the same unvalidated, uncoerced path that the
runner pod metadata used to: an invalid label only failed once the
controller created the listener pod, which is the silent failure mode
this change set exists to remove. Both charts now validate it at render
time and route its values through the string coercion.
Values loaded from a values file arrive as float64, so "%v" rendered a
large integer such as 12345678901234 in scientific notation, silently
corrupting the annotation. Integral floats are now formatted without an
exponent, and the remaining sites that quoted metadata values directly
go through the same helper.
A map or list value was flattened into Go's own formatting, producing a
meaningless "map[a:b]" label. Such values are now rejected with the
values path that produced them.
The label key prefix check rejected dot-separated segments longer than
63 characters. Kubernetes only bounds the prefix at 253 characters in
total, so the check was stricter than the API server and would have
rejected keys that already work.
While covering the listener path, the experimental chart turned out to
render invalid YAML whenever listener.podTemplate carried both metadata
and spec: the last metadata value and the following "spec:" key ended up
on the same line. That is fixed here too, with a regression test.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
The validation helpers ranged over labels/annotations without checking they
were maps, and silently skipped non-map resourceMeta entries. A mis-typed
value therefore escaped validation and failed later with an opaque error
such as 'range can't iterate over oops' or 'can't evaluate field labels in
type interface {}', which is the class of error this validation exists to
replace.
Guard every metadata map with an explicit type check that names the values
path, and run the validation from every template that renders metadata so
the reported error does not depend on which template Helm renders first.
Also add coverage for scalar coercion driven by a values file. SetValues
only ever produces strings, so the existing tests could not exercise the
bool/number values that stringMap is there to handle.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
The batched review suggestion introduced a per-segment DNS subdomain check
for the key prefix, but consumed the 'end' that closed the prefix branch.
That left the block unbalanced, so every template in both charts failed to
parse, and it also moved the name-part check inside the prefix branch where
it would only run for prefixed keys.
Close the prefix branch explicitly and bind kind/path before the range,
since the range rebinds the dot and '.path'/'.kind' are not reachable
inside it. Also correct the segment error message, which described the
253 character limit rather than the constraint that actually failed.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Invalid labels supplied through .Values.template.metadata.labels (or the
resourceMeta blocks) are not rejected by the API server: they live inside
the AutoscalingRunnerSet spec, whose CRD schema only enforces the value
type. The invalid value is only caught when the controller creates the
runner pod, at which point the EphemeralRunner is marked as failed with
ReasonInvalidPodFailure and the scale set never produces runners.
Validate every label and annotation map the charts render against the
Kubernetes key/value rules so helm install/upgrade fails immediately with
the offending values path, key and value.
Also render all metadata values as strings. Scalars such as 'true' or '1'
were previously emitted as YAML booleans and numbers, which Kubernetes
rejects for labels and annotations.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
