2026-08-27 · 6 min read · Rahul Chitturi
- yaml
- ci
- debugging
A YAML value that looks like a short string can become a boolean under an older schema. YAML 1.1 commonly treats words such as yes, no, on, and off as booleans, while YAML 1.2 narrows the usual boolean spellings.
The mismatch appears when local tooling, a CI platform, and an application use different parsers or schemas. A matrix label, environment value, or feature name can silently change type before the job starts.
Inspect the parsed shape
Reduce the failure to a safe YAML fragment and convert it to JSON with the same parser settings used by the target platform. The JSON form makes strings and booleans unambiguous.
- Check the platform's documented YAML version or schema
- Quote string identifiers that resemble booleans, nulls, dates, or numbers
- Compare local lint output with the CI parser result
- Inspect keys as well as values for implicit conversion
Quote contracts, not every scalar
Quote values that must remain strings, especially environment variables, matrix labels, version numbers, and user-defined identifiers. Keep actual booleans as true or false so intent remains obvious.
Broad automated quoting can change downstream behavior or obscure numeric fields. Fix the schema boundary and add a fixture for the exact ambiguous values your configuration accepts.
A Flashman workflow
Use the YAML/JSON converter to expose parsed types, the JSON formatter to inspect nested output, the diff tool to compare parser results, and the case converter to normalize identifiers only when the contract calls for it.
Commit a regression example with on, off, yes, and no alongside explicit booleans. A reviewer should be able to see which values are labels and which control behavior.