Cole dois documentos YAML e obtenha um diff preciso lado a lado. Pensado para manifests do Kubernetes, workflows do GitHub Actions, values do Helm e arquivos docker-compose.
Uma ferramenta gratuita no navegador para comparar dois documentos YAML. Cole a versão antiga à esquerda, a nova à direita, e as diferenças aparecem destacadas caractere a caractere. O texto não sai do seu navegador, o que importa quando você está dando diff em manifests com referências a secrets ou hostnames internos.
O diff é em nível de caractere, o mesmo motor que a nossa ferramenta de diff de texto usa. O modo YAML do editor faz o syntax highlighting de acordo com a especificação YAML 1.2.2, então seus block scalars, anchors e flow collections aparecem com as cores certas.
Se você já encarou um diff de 400 linhas de um values.yaml de Helm em um pull request tentando achar o desnível de indentação que quebrou o chart, esta é a ferramenta que encontra isso em segundos. Também ajuda quando o copiar e colar entre o Slack e seu editor converte espaços em tabs, que o YAML se recusa a aceitar.
O diff roda em nível de caractere e depois uma passagem de limpeza semântica agrupa os destaques em blocos com sentido em vez de caracteres soltos espalhados. As inserções aparecem em verde no painel direito, as remoções em vermelho à esquerda, e os contadores de cada cabeçalho dizem quantas edições distintas o diff achou.
YAML tem regras de parsing que mordem quem trata o formato como tolerante. A indentação é estrutural conforme a spec YAML 1.2.2, então um único espaço fora do lugar muda a árvore do documento. Tabs são proibidos como indentação, e o parser rejeita direto. O typing implícito transforma o token sem aspas NO no booleano false em YAML 1.1, o famoso Norway problem: listas de códigos de país perdem a Noruega em silêncio. O YAML 1.2 apertou as regras para que apenas true, false, null e formas numéricas se convertam sem aspas, mas muita ferramenta ainda parseia como 1.1.
Se você já converteu seu YAML para JSON para um consumidor downstream, nossa ferramenta de diff de JSON cuida das questões estruturais como ordem de chaves e canonicalização. JSON é um subconjunto estrito de YAML 1.2, então qualquer documento JSON válido também é YAML válido: essa compatibilidade está na spec e é por isso que js-yaml e libyaml conseguem fazer round-trip de JSON sem surpresas.
Dois painéis de texto, um diff. Sem cadastro, sem upload, sem ida ao servidor.
Cole o YAML antigo à esquerda, o novo à direita. Ou clique em Upload de qualquer um dos lados para carregar diretamente um arquivo .yaml ou .yml. O botão Exemplo preenche os dois painéis com um Deployment pequeno do Kubernetes para você ver a ferramenta funcionando primeiro.
YAML usa só espaços para indentação, nunca tabs. Se você colou de um chat ou terminal que converteu espaços em tabs, o parser vai rejeitar o arquivo. O editor destaca tabs e espaços em fim de linha para você notá-los antes que causem falha em um deploy.
Remoções aparecem em vermelho à esquerda, inserções em verde à direita. Os dois painéis rolam juntos para você acompanhar manifests longos sem se perder. Os contadores de mudanças em cada cabeçalho resumem quantas edições distintas o diff encontrou.
Rode kubectl get deployment web -o yaml nos dois clusters e dê diff na saída. Muitas vezes prod ainda está com replicas: 2 e uma image tag antiga porque um rollout de fim de sprint nunca chegou lá, e um diff de texto é a forma mais rápida de confirmar isso antes de rodar kubectl apply de novo. O modelo de objetos do Kubernetes é YAML do início ao fim, então este é o caso do dia a dia.
Quando um workflow para de disparar depois de renomear uma branch ou um job leva 8 minutos a mais de repente, dê diff de .github/workflows/ci.yml contra o último commit verde. O culpado costuma ser um filtro on: alterado, uma chave cache: removida no actions/setup-node, ou uma entrada da matriz que mudou silenciosamente de node-version: "18" (string) para node-version: 18 (número) e quebrou o type checker.
Dê diff de docker-compose.yml contra a versão na main para verificar quais entradas de environment: você realmente mudou. As pessoas colam uma lista de novas variáveis e esquecem que uma delas já estava setada em outro service, e o override muda uma flag em outro lugar sem avisar. O diff deixa isso óbvio.
Ao subir um chart de 1.8.0 para 2.0.0, dê diff do seu values.yaml contra os novos defaults publicados pelo mantenedor. O Helm faz merge dos values chave a chave, então uma chave de topo renomeada (image.tag indo para baixo de image.repository) cai silenciosamente no default do chart. O diff faz a renomeação aparecer antes que o helm upgrade faça rollout de uma regressão.
Um diff de um openapi.yaml de 3.000 linhas é ilegível quando um gerador de código reordena os paths em ordem alfabética. Compare as versões lado a lado e a mudança real aparece: um campo required adicionado a um schema de request, ou uma response cujo tipo mudou silenciosamente de string para integer. Mais fácil que cavar um SDK gerado para achar por que a build quebrou.
Quando um playbook funciona em dev e falha em prod, dê diff do inventory ou do defaults/main.yml da role entre os dois. Uma causa comum é uma hostvar que nunca foi copiada, ou um become: yes setado na role em dev mas em uma única task em prod. O diff acha em segundos.
Uma cola curta para os casos limite de parsing que esta ferramenta destaca com mais frequência. Tudo baseado na especificação YAML e no comportamento real dos parsers.
| Topic | What this tool does |
|---|---|
| Indentação | Apenas espaços, e a contagem é estrutural. Dois e quatro espaços são ambos comuns; escolha um por arquivo e mantenha. A página de YAML na Wikipédia tem um bom resumo se quiser a história. |
| Tabs | Proibidos como indentação pela spec. Permitidos dentro de valores escalares. Se seu editor insere um tab no Enter, configure-o para usar espaços em arquivos .yaml e .yml. |
| Anchors e aliases | &name define um anchor; *name faz referência. Útil para repetir blocos grandes como env vars de container ou config padrão de service sem copiar e colar. |
| Merge keys | <<: *base faz merge do mapping referenciado no atual. Recurso de YAML 1.1. A maioria dos parsers, incluindo libyaml, ainda aceita; a spec do YAML 1.2 derrubou. |
| Arquivos multi-document | Três traços (---) separam documentos em um único stream. Útil para empurrar vários objetos do Kubernetes por um único kubectl apply -f. ... encerra um documento. |
| Block scalars | | preserva quebras de linha (literal); > dobra em espaços. Os modificadores - e + controlam quebras finais. Use | para scripts de shell, > para prosa longa. |
| Norway problem | Sem aspas, NO, YES, ON, OFF viram booleanos em YAML 1.1. Coloque entre aspas ou use um parser 1.2. Veja as definições de tipos do YAML para saber quais strings são convertidas. |
| Codificação | A spec do YAML 1.2 exige UTF-8. UTF-16 é permitido com BOM. Na prática, as ferramentas esperam UTF-8 sem BOM, então salve seus arquivos assim para evitar surpresas. |
YAML é sensível a whitespace, então um diff de texto comum já é útil: qualquer mudança de indentação é uma mudança estrutural, e o diff captura. A diferença está na apresentação. O modo YAML colore anchors, tags, block scalars e flow collections com as cores da sintaxe, então você sabe num relance se a mudança é em uma chave, um valor string ou um item de lista. O algoritmo de diff por baixo é o mesmo da nossa ferramenta de diff de texto.
Porque a indentação é a única coisa que diz ao parser quais chaves pertencem a qual mapping. A spec do YAML 1.2.2 define o nível de indentação de um nó pela quantidade de espaços iniciais, e proíbe tabs como indentação. Um espaço a mais já promove uma chave a um sub-mapping. Esse rigor é o preço por um formato que dispensa chaves e vírgulas, e é por isso que se vê mais bug de indentação em YAML do que em JSON.
O typing implícito do YAML 1.1 transforma o token sem aspas NO no booleano false. Então uma lista de códigos de país que inclui NO para Noruega vira silenciosamente uma lista com uma entrada substituída por false. O mesmo vale para YES, ON, OFF e companhia. A StrictYAML documenta isso em detalhe. A correção é colocar o valor entre aspas ("NO") ou usar um parser que siga YAML 1.2, que só converte true, false e null implicitamente.
Um anchor (&name) marca um nó para você referenciá-lo depois com um alias (*name), evitando repetição em arquivos longos. A merge key (<<: *name) era uma extensão do YAML 1.1 que copia todas as chaves do mapping referenciado para o atual, útil para compartilhar configuração comum entre services. Merge keys não fazem parte do YAML 1.2, mas a maioria dos parsers, incluindo o js-yaml, ainda aceita por compatibilidade. O diff trata anchors e aliases como texto puro, então um anchor renomeado aparece de forma limpa.
Pode. JSON é um subconjunto estrito de YAML 1.2, então qualquer documento JSON válido também é um documento YAML válido. Você pode misturar os dois se quiser mesmo, jogando uma flow collection no estilo JSON dentro de um arquivo em estilo bloco. Para trabalho com JSON puro, nossa ferramenta de diff de JSON tem botões de formatar e validar específicos para JSON, incluindo pretty-print e ordenar chaves.
Porque a spec do YAML proíbe tabs como indentação. Citando a spec 1.2.2: "To maintain portability, tab characters must not be used in indentation." Tabs são permitidos dentro de valores escalares (uma string pode conter um tab), só não no início da linha, onde a indentação é medida. A correção é um find-and-replace rápido de tab para dois ou quatro espaços, conforme a convenção que seu arquivo já usa.
Seu YAML não sai do seu navegador. O editor, o syntax highlighter e o diff rodam todos na sua máquina, localmente. Sem analytics na sua entrada, sem logs, sem ida à nuvem. O formato que seguimos é a especificação YAML 1.2.2. Para confirmar que nada é enviado, abra as DevTools e fique de olho na aba Network enquanto compara.