Validateur YAML

D’abord la syntaxe : indentation, tabulations, crochets et guillemets non fermés, mappings et séquences mal formés. Ensuite la structure : clés en double, alias pointant vers des ancres jamais déclarées, expansion d’alias incontrôlée. Enfin la portabilité : les tags personnalisés comme !Ref, qui n’ont aucun sens hors de leur outil, et chaque valeur sans guillemets que YAML 1.1 et YAML 1.2 lisent différemment. Chaque problème arrive avec la ligne et la colonne, une explication en langage clair, une correction suggérée et un repère dans l’éditeur.

Parce que valide ne veut pas dire correct. country: no s’analyse sans erreur dans les deux versions de YAML, mais c’est la chaîne "no" en YAML 1.2 et le booléen false en YAML 1.1 ; c’est ainsi qu’un pays disparaît d’une liste sans la moindre erreur. Il en va de même pour 022, 12:30 et 1e3. Ce validateur les signale comme des avertissements et non des erreurs : le document s’analyse, mais un autre outil lirait une valeur autrement. Mettez la valeur entre guillemets pour lever l’ambiguïté.

L’analyseur a rencontré un deux-points suivi d’un espace à un endroit où il lisait déjà une valeur. La cause habituelle est une valeur sans guillemets qui contient elle-même un deux-points, comme title: Deploy: production ou une URL écrite sans guillemets. Entourez la valeur de guillemets. L’autre cause est une clé indentée différemment des clés voisines, que l’analyseur lit alors comme la suite de la valeur précédente.

Presque toujours une tabulation utilisée pour l’indentation, ce que YAML interdit. Les éditeurs qui convertissent les tabulations en espaces masquent le problème jusqu’à ce que le fichier soit modifié ailleurs. Remplacez la tabulation par des espaces et gardez la même largeur pour toutes les clés sœurs ; le validateur indique la ligne exacte. Le même message apparaît pour un caractère de contrôle égaré ou pour un @ ou un accent grave en début de valeur.

L’analyseur lisait un mapping et attendait, sur la ligne suivante, une autre clé à la même indentation, mais a trouvé autre chose. Regardez la ligne qui précède celle signalée : une valeur indentée d’un espace de plus que ses sœurs, un tiret qui ouvre une liste là où une clé était attendue, ou une valeur qui aurait dû être entre guillemets. Le validateur retrouve la vraie cause pour les crochets et guillemets non fermés, que la plupart des analyseurs signalent à tort sous ce message.

Non. Il vérifie que le document est du YAML bien formé et qu’il signifie la même chose pour tous les analyseurs ; il ne sait pas quelles clés un Deployment ou un document OpenAPI peut contenir. Pour Kubernetes, kubectl apply --dry-run=client -f fichier.yaml vérifie un manifeste contre le schéma du cluster. Pour OpenAPI, GitHub Actions ou JSON Schema, passez le fichier dans le validateur de schéma de ce format une fois qu’il est accepté ici.

Non. La validation s’exécute dans votre navigateur ; il n’existe aucun point de terminaison auquel envoyer le document, et la page continue de fonctionner une fois déconnectée. Les fichiers de configuration sont exactement le genre de choses qui contiennent des noms d’hôte, des chemins internes et parfois un secret, et c’est pour cela que l’outil a été conçu ainsi.

yamllint fichier.yaml signale les erreurs de syntaxe et les problèmes de style et reste le choix habituel en CI. yq . fichier.yaml affiche le document ou échoue avec une erreur d’analyse. En Python, python -c "import sys, yaml; yaml.safe_load(sys.stdin)" < fichier.yaml échoue sur du YAML invalide, mais PyYAML lit du YAML 1.1 et traitera donc aussi no comme false. Aucun n’explique l’erreur comme le validateur ci-dessus : utilisez-les pour faire échouer un pipeline, et cette page pour comprendre pourquoi.