YAML 1.1 Silent Type Changes: yes, 0755, 3.0 and Friends
YAML has no schema, so a parser decides each unquoted scalar's type by pattern. YAML 1.1 and 1.2 disagree on several patterns, and plenty of tooling still follows 1.1 rules. The linter flags each pattern below by line number.
| You write | A YAML 1.1 parser reads | Write instead |
|---|---|---|
enabled: yes | boolean true | enabled: true, or "yes" if you mean the word |
answer: no | boolean false | "no" |
country: NO | boolean false (the Norway problem) | "NO" |
mode: 0755 | octal, the number 493 | "0755", or 0o755 where 1.2 is supported |
zip: 01234 | octal, the number 668 | "01234" |
version: 3.0 | the float 3 | "3.0" |
version: 1.10 | the float 1.1 | "1.10" |
y: 1 | key becomes boolean true | "y": 1 |
true and false are booleans in every version, so they are not on this list.
Which parsers follow which
This varies by library and version, so check the one you use rather than trusting a table. As a rule: libraries built on the original libyaml and PyYAML-style resolvers follow 1.1 booleans (yes, no, on, off); parsers written for 1.2 only treat true and false as booleans. A file that works in one tool can change meaning in another, which is the reason to quote.
on: in GitHub Actions
Workflow files use a top-level on: key. Under 1.1 rules that key is the boolean true, and GitHub's parser accepts it deliberately. The linter reports it as information, not a warning. Anywhere else, quote it.
Duplicate keys
YAML says keys in a mapping must be unique, but many parsers accept a duplicate and keep the last one without complaint. A second env: block lower in a file can silently replace the first. The linter reports duplicates within one mapping as an error.
What the linter does not do
It reads text, not structure, so it cannot know that a value is in a field your tool treats as a string. It will flag mode: 0755 even where the consumer reads it as text. Quote it anyway: it costs nothing and removes the doubt.