Validar gitlab-ci.yml online, antes que o runner ache o erro.

Cole o conteúdo do seu .gitlab-ci.yml na caixa acima e a validação roda na hora, dentro do navegador. Você recebe duas coisas ao mesmo tempo. Primeiro, ele analisa o YAML e reporta erros de sintaxe, indentação incorreta e falhas estruturais, indicando a linha que quebrou. Segundo, ele roda verificações de configuração de pipeline incorreta que correspondem à forma como o próprio GitLab valida uma config: um job sem script / run / trigger / extends, um job cujo stage não está na sua lista de stages, referências em needs e extends que apontam para jobs que não existem, um valor de when inválido, um bloco rules que não é uma lista, only/except legados e formatos incorretos de image/services. É um jeito rápido de verificar o pipeline do GitLab sem sair do navegador.

Sim. Diferente do CI Lint embutido do GitLab, este validador de GitLab CI YAML não exige um projeto, um repositório nem um login. Cole o .gitlab-ci.yml direto no navegador e ele roda o conjunto completo de verificações localmente. Como nada é enviado para um servidor, você pode colar com segurança pipelines internos ou proprietários — inclusive os que têm tags de runner privadas, nomes de imagens internas e referências a variáveis secretas.

Essa mensagem aparece quando o GitLab consegue ler o YAML, mas a configuração do pipeline não respeita as regras dele. As causas mais comuns são estruturais: um job apontando para um stage que não está em stages:, um job sem script / run / trigger / extends, uma entrada em needs ou extends que nomeia um job que não existe, um valor de when inválido ou um bloco rules escrito como mapeamento em vez de lista. O validador reproduz essas mesmas verificações e aponta exatamente qual linha torna a config inválida, com uma correção concreta para cada caso.

Cole o YAML do pipeline neste validador baseado em navegador para detectar erros antes de fazer commit — sem instalar nada e sem precisar de push. A ferramenta roda o conjunto completo de verificações (estrutura YAML mais configurações de pipeline incorretas) inteiramente no seu navegador, então você recebe feedback instantâneo sobre erros de sintaxe, stages não declarados, jobs sem scripts, needs/extends quebrados e valores de when inválidos antes que a config chegue a um runner do GitLab. Trate um resultado limpo aqui como uma sólida confiança antes do push e depois confirme com o CI Lint do GitLab.

Sim — esta página é exatamente isso. Você pode validar o seu .gitlab-ci.yml online de graça, sem cadastro, sem conta e sem instalar nada. O validador roda 100% no lado do cliente: o arquivo é analisado e examinado dentro da aba do seu navegador, e nada é enviado para um servidor. O CI Lint do GitLab também é gratuito, mas exige um projeto e um login; aqui você só precisa colar o YAML.

Além da validade do YAML, ele roda as verificações estruturais de alto sinal que correspondem ao que o GitLab valida: stages não declarados, um job sem script / run / trigger / extends, referências em needs / dependencies / extends que apontam para jobs ou templates inexistentes, valores de when inválidos, blocos rules que não são listas, only/except legados e formatos incorretos de image/services. Cada achado é classificado como erro, aviso ou info, e os erros que quebram o pipeline sobem para o topo. Templates ocultos (chaves que começam com um ponto) podem ser fragmentos parciais, então não são obrigados a ter um script.

O erro "did not find expected key" é um erro de YAML, não de pipeline: o leitor de YAML esperava uma chave de mapeamento e encontrou indentação inconsistente, dois-pontos faltando ou um item de lista mal alinhado. Quase sempre é espaçamento — use sempre dois espaços por nível e nunca tabs. O validador aponta a linha exata em que o YAML quebra, para você corrigir a indentação antes mesmo de chegar às verificações de configuração do pipeline.

Um job visível do GitLab tem que fazer alguma coisa. Um job comum roda comandos com script: (ou o mais novo run:), um job-ponte inicia um pipeline downstream com trigger:, e um job pode herdar qualquer um desses de outro job ou de um template oculto via extends:. Um job visível que não define nenhum deles é rejeitado pelo GitLab com um erro como "job config should implement a script: or a trigger: keyword". O validador sinaliza qualquer job visível que não tenha um desses quatro. Templates ocultos (chaves que começam com um ponto) podem ser fragmentos parciais, então não precisam de um script.