class

Krikri::YamlSyntaxError

Represents an entire playbook A YAML syntax error in a playbook, carrying enough structure to be rendered the way ansible-playbook renders one (see #render). Previously this was a bare raise "Invalid YAML in ...", which lost the position and printed nothing like Ansible's output.

Constants

COLON_DETAIL = "mapping values are not allowed in this context"

libyaml's own wording for the single most common playbook YAML mistake (an unquoted value containing ": "), kept as the fallback for when ansible's colon heuristic (below) does not fire on the offending line.

COLON_MESSAGE = "Colons in unquoted values must be followed by a non-space character."

QUOTED_VALUE_RE = /\A\s*('[^']*'|"[^"]*")\s*\z/

QUOTING_MESSAGE = "This may be an issue with missing quotes around a template block."

ansible-core's loader refuses a collection used as a mapping key with its own wording (not libyaml's - libyaml parses key: {{ x }} happily as a flow-mapping key); verified against 2.19: rc=4, this exact message, and the same worked-example block the colon error appends, with a template-shaped example instead.

TAB_DETAIL = "found a tab character"

TAB_MESSAGE = "Tabs are usually invalid in YAML."

TRUNCATED_NOTE = "(source not shown: file truncated)"

UNQUOTED_COLON_RE = /:(\z| )/

VALUE_LINE_RE = /\A\s*(?:-\s+)*(?:[\w\s\[\]{}]+:\s+)?(?<value>.*)\z/

ansible-core's error layer (lib/ansible/_internal/_yaml/_errors.py) runs one regex heuristic over the offending SOURCE line for EVERY libyaml parse error, whatever libyaml's own complaint was: the "value" left after the line's - list and key: preamble is blanked out when it is a single-line quoted scalar, and any colon still followed by a space or end-of-line is reported as "Colons in unquoted values..." with the Origin re-pointed at that colon. libyaml's own position is often nowhere near the colon - a task key landing at column 1 after a mis-indented multi-line scalar (rothgar.tomcat_and_java's tasks/main.yml:10, issue #816) reports the block-collection error there - so both message and column come from the heuristic, not from libyaml.

Constructors

new(path : String, content : String, line : Int32, column : Int32, detail : String)

The quoting refusal has no libyaml cause at all: the file parses fine here (and the position comes from the source map's collection-as-key detection, not from a parse exception), so the detail is Ansible's own message verbatim - no normalize.

Source

new(path : String, content : String, cause : YAML::ParseException)

Source

Class methods

normalize(message : String) : String

Crystal's YAML::ParseException message inlines the position and puts libyaml's CONTEXT last:

"did not find expected ',' or ']' at line 3, column 1, while parsing a flow sequence"

Ansible renders libyaml's two halves the other way round, capitalized and full-stopped:

"While parsing a flow sequence did not find expected ',' or ']'."

(verified against ansible-core 2.19.4). Reorder to match.

Source

Instance methods

colon_error?

column

detail

line

path

quoting_error?

render

ansible-playbook's own layout, verified against ansible-core 2.19.4:

[ERROR]: YAML parsing failed: <message>
Origin: /abs/path.yml:1:9

1 this: is: bad: [
          ^ column 9

Source

tab_error?

Source