Verificador de indentação e sintaxe YAML com linhas

Este verificador de indentação e sintaxe YAML encontra pequenos erros estruturais que tornam arquivos de configuração pouco confiáveis: tabulações escondidas no espaço inicial, mudanças inesperadas na profundidade da indentação e chaves repetidas no mesmo mapeamento. Cada ocorrência inclui a linha de origem, para que você possa ir diretamente à configuração incorreta. O verificador também rejeita texto que não possa ser interpretado como YAML, separando entradas malformadas de documentos válidos que apenas apresentam avisos de lint.

Leia um relatório objetivo em vez de perseguir mensagens do parser

Cole o documento YAML completo no campo de texto e execute a verificação. O resultado informa se o documento passou, apresenta o total de ocorrências e lista cada problema com número de linha iniciado em um, tipo estável e explicação. Esse formato compacto atende tanto quem revisa um arquivo de implantação quanto um script que confere configurações geradas.

O verificador concentra-se em três riscos estruturais comuns. Ele encontra tabulações no espaço inicial, pois editores podem exibi-las com larguras diferentes. Também detecta mudanças de indentação incompatíveis com a estrutura definida pelos nós superiores.

Além disso, acompanha as chaves por escopo: a mesma grafia pode existir em objetos distintos, mas uma repetição dentro do mesmo objeto é informada. Comentários e linhas vazias não alteram as referências. Uma resposta limpa traz um array de erros vazio, sem valores artificiais, facilitando seu uso como uma etapa aprovada em builds ou fluxos anteriores ao commit.

Entenda a diferença entre ocorrências de lint e entrada inválida

Uma ocorrência de lint descreve texto que ainda pode ser examinado de forma útil, embora sua estrutura seja arriscada. Uma tabulação na indentação ou uma chave duplicada, por exemplo, gera um resultado normal com a linha correspondente. Uma falha de parsing é diferente: o documento está tão incompleto ou malformado que uma análise estrutural confiável não pode continuar.

Aspas não terminadas, delimitadores de coleções de fluxo sem par, chaves de mapeamento vazias ou uma linha simples onde se exige um mapa ou uma sequência causam erro de entrada inválida. Separar esses resultados ajuda na automação. Sua integração pode mostrar todas as ocorrências recuperáveis de uma vez, enquanto uma falha de parsing interrompe o pipeline e solicita o reparo da fonte.

A verificação é determinística: ela não reescreve o documento, não escolhe valores duplicados nem adivinha o aninhamento desejado. Em configurações, alterar o sentido silenciosamente costuma ser pior que rejeitar o arquivo. Corrija primeiro a falha mais antiga, verifique novamente e trate depois os avisos restantes com linhas numeradas.

Use o verificador com segurança em editores e pipelines de entrega

Envie o texto-fonte exato, e não um objeto já processado, porque a indentação e as chaves duplicadas desaparecem quando muitos parsers convertem YAML em dados comuns. Preserve finais de linha e comentários para que as posições coincidam com o editor. Um pipeline prático pode fazer esta verificação após a aplicação de templates e antes da inclusão de segredos, falhando quando valid é false ou quando surge um erro de entrada inválida.

A resposta é estável para textos idênticos: não usa rede, aleatoriedade, relógio ou estado do ambiente. Limites de entrada e de linhas impedem trabalho ilimitado. Trata-se deliberadamente de lint estrutural básico, não de validação de esquema.

Ele não sabe se um campo do Kubernetes, uma propriedade de workflow ou uma opção do aplicativo é permitida. Quando a semântica importar, combine-o com o validador de esquema do sistema de destino.