YAML Validator

Zuerst die Syntax: Einrückung, Tabulatoren, nicht geschlossene Klammern und Anführungszeichen sowie fehlerhafte Mappings und Sequenzen. Dann die Struktur: doppelte Schlüssel, Aliases auf nie deklarierte Anchors und außer Kontrolle geratene Alias-Auflösung. Zuletzt die Portabilität: eigene Tags wie !Ref, die außerhalb ihres Werkzeugs nichts bedeuten, und jeder unzitierte Wert, den YAML 1.1 und YAML 1.2 unterschiedlich lesen. Jedes Problem kommt mit Zeile und Spalte, einer verständlichen Erklärung, einem Lösungsvorschlag und einer Markierung im Editor.

Weil gültig nicht dasselbe ist wie korrekt. country: no parst in beiden YAML-Versionen fehlerfrei, ist aber in YAML 1.2 der String "no" und in YAML 1.1 der Boolean false — so verschwindet ein Land ohne jede Fehlermeldung aus einer Liste. Dasselbe gilt für 022, 12:30 und 1e3. Dieser Validator meldet solche Werte als Warnungen statt als Fehler: Das Dokument parst, aber ein anderes Werkzeug würde einen Wert anders lesen. Setze den Wert in Anführungszeichen, um ihn eindeutig zu machen.

Der Parser hat einen Doppelpunkt mit folgendem Leerzeichen an einer Stelle gefunden, an der er bereits einen Wert las. Die übliche Ursache ist ein unzitierter Wert, der selbst einen Doppelpunkt enthält, etwa title: Deploy: production oder eine URL ohne Anführungszeichen. Setze den Wert in Anführungszeichen. Die andere Ursache ist ein Schlüssel, der anders eingerückt ist als die Schlüssel um ihn herum, sodass der Parser ihn als Teil des vorherigen Werts liest.

Fast immer ein Tabulator, der zum Einrücken verwendet wurde — YAML verbietet das. Editoren, die Tabulatoren in Leerzeichen umwandeln, verbergen das Problem, bis die Datei woanders bearbeitet wird. Ersetze den Tabulator durch Leerzeichen und halte alle Geschwisterschlüssel auf derselben Breite; der Validator zeigt auf die genaue Zeile. Dieselbe Meldung erscheint bei einem verirrten Steuerzeichen oder einem @ oder Backtick am Anfang eines Werts.

Der Parser las ein Mapping und erwartete in der nächsten Zeile einen weiteren Schlüssel mit derselben Einrückung, fand aber etwas anderes. Sieh dir die Zeile vor der gemeldeten an: ein Wert mit einem Leerzeichen mehr Einrückung als seine Geschwister, ein Bindestrich, der eine Liste beginnt, wo ein Schlüssel erwartet wurde, oder ein Wert, der in Anführungszeichen gehört hätte. Bei nicht geschlossenen Klammern und Anführungszeichen, die die meisten Parser fälschlich unter dieser Meldung ausgeben, findet der Validator die tatsächliche Ursache.

Nein. Er prüft, ob das Dokument wohlgeformtes YAML ist und für jeden Parser dasselbe bedeutet; welche Schlüssel ein Deployment oder ein OpenAPI-Dokument enthalten darf, weiß er nicht. Für Kubernetes prüft kubectl apply --dry-run=client -f datei.yaml ein Manifest gegen das Schema des Clusters. Für OpenAPI, GitHub Actions oder JSON Schema schickst du die Datei durch den Schema-Validator des jeweiligen Formats, sobald sie hier durchgeht.

Nein. Die Validierung läuft in deinem Browser; es gibt keinen Server-Endpunkt, an den das Dokument geschickt werden könnte, und die Seite funktioniert auch nach dem Trennen der Verbindung weiter. Konfigurationsdateien enthalten genau die Art von Dingen — Hostnamen, interne Pfade und gelegentlich ein Geheimnis —, wegen der das Werkzeug so gebaut wurde.

yamllint datei.yaml meldet Syntaxfehler und Stilprobleme und ist die übliche Wahl in CI. yq . datei.yaml gibt das Dokument aus oder scheitert mit einem Parse-Fehler. In Python scheitert python -c "import sys, yaml; yaml.safe_load(sys.stdin)" < datei.yaml bei ungültigem YAML — PyYAML liest allerdings YAML 1.1 und behandelt daher auch no als false. Keines davon erklärt den Fehler so wie der Validator oben: Nutze sie, um eine Pipeline scheitern zu lassen, und diese Seite, um herauszufinden, warum.