Detect Type Mismatches Between Default and Override Values

Type Mismatch Detection

YAML's automatic type inference can cause subtle bugs when override values have a different type than the defaults. The comparison mode detects these mismatches.

Common Type Mismatch Scenarios

Number vs String:

# Default
service:
  port: 80        # number

# Override
service:
  port: "8080"    # string - type mismatch!

Boolean vs String:

# Default
ingress:
  enabled: false  # boolean

# Override
ingress:
  enabled: "true" # string - type mismatch!

YAML Auto-Typing Surprises:

# These are all boolean in YAML:
enabled: yes    # true
enabled: no     # false
enabled: on     # true
enabled: off    # false

# These are null:
value: ~
value: null

# This is a float, not a version string:
tag: 1.0        # number 1.0, not string "1.0"

What Gets Detected

The validator compares the JavaScript type of each value path between default and override:

Default Type	Override Type	Severity	Example
number	string	warning	port: 80 vs port: "80"
boolean	string	warning	enabled: false vs enabled: "false"
array	object	warning	tolerations: [] vs tolerations: {}
string	number	warning	tag: "1.0" vs tag: 1.0
null	any	skipped	null defaults are flexible

How to Fix Type Mismatches

1. Quote strings: Always quote values that should be strings but look like numbers or booleans ("1.0", "true")
2. Use YAML literal syntax: !!str 80 forces a string type
3. Check YAML parsing: Use the tree view to see how the YAML parser interprets your values
4. Be explicit: enabled: true not enabled: yes

Why Types Matter

Helm templates use Go's template language, which is type-aware. A template expecting a boolean will behave differently with the string "true":

{{- if .Values.ingress.enabled }}
# "true" (string) is truthy, but string comparison fails:
{{- if eq .Values.ingress.enabled true }}  # false for string "true"!