Ferramentas de CI/CD

validador GitHub Actionsformate, valide e navegue por cada job

Cole um workflow YAML para formatá-lo, percorrer a árvore de job/step e pré-visualizar um rascunho de matrix ou cron antes de inserir.

Validação automática

YAML do workflow

Resultado

Tudo roda no navegador; nada é enviado ao GitHub ou a qualquer servidor.

OpçõesIndentação

Gerador de matrix (rascunho)

Variáveis

include (opcional)

exclude (opcional)

fail-fastmax-parallel (opcional)Inserir no job

Gere uma pré-visualização para ver o trecho de strategy.matrix.

Gerador de agendamento cron (rascunho)

Expressão cron (5 campos)Fuso horário (opcional)

Gere uma pré-visualização para ver o trecho de on.schedule.

Aguardando validação…

Um arquivo workflow YAML do GitHub Actions costuma quebrar só depois do push — um job sem runs-on, um valor de permissions que nem existe na enumeração real, ou um agendamento que nunca dispara silenciosamente. Este validador GitHub Actions pega esse tipo de erro localmente, antes de qualquer run começar, verificando a estrutura da qual a CI realmente depende, não só a sintaxe YAML genérica.

Vale a pena usar ao editar à mão um workflow com vários jobs e precisar achar rápido qual está quebrado, ao montar uma matriz de build com sistemas operacionais e versões diferentes, ao organizar referências env, secrets e vars espalhadas por vários steps, ou ao escrever uma expressão cron em on.schedule e precisar saber o que o GitHub Actions realmente permite.

Por que usar este validador GitHub Actions

Uma única bancada em vez de alternar entre um linter YAML genérico, um gerador de matrix e uma ferramenta de cron que não conhece o GitHub Actions.

Formatação, validação de estrutura e navegação job/step juntas

Ao colar um workflow, o YAML é formatado, o id de job e de step é verificado contra a regra de nomenclatura, cada job é confirmado com runs-on ou uses, os valores de permissions são validados contra a enumeração real (id-token só aceita write ou none) e filtros mutuamente exclusivos como branches e branches-ignore usados juntos são sinalizados — depois uma árvore de job/step clicável leva o editor direto para a linha certa.

Ver regras e limites

Workflow YAML do GitHub Actions formatado ao lado de uma árvore de navegação job/step clicável com um erro de estrutura destacado

Ver exatamente onde as referências env, secrets e github vão quebrar

O painel de referências lista cada expressão ${{ env.X }}, ${{ secrets.X }}, ${{ vars.X }} e ${{ github.X }} encontrada, com o job e o step correspondentes, e sinaliza os três pontos de falha documentados: env não pode ser usado no id nem no uses de um step, secrets não pode ser lido diretamente numa condição if:, e github não pode ser usado dentro de uses:.

Ver como as referências são extraídas

Lista de referências env, secrets, vars e github com três entradas sinalizadas nos pontos em que o GitHub Actions realmente rejeita a expressão

Um gerador de cron que já conhece os limites próprios do GitHub Actions

O painel de cron monta uma expressão padrão de cinco campos aplicando as restrições que o GitHub documenta para gatilhos schedule: intervalo mínimo de cinco minutos, UTC por padrão com fuso IANA opcional, sem aliases como @daily, e a desativação automática após 60 dias sem atividade em repositórios públicos.

Ler o FAQ sobre agendamento

Gerador de cron mostrando o intervalo mínimo de cinco minutos, o fuso UTC padrão e um aviso de alias não suportado pelo GitHub Actions

Três coisas fáceis de passar batido na primeira vez

A bancada faz mais coisas automaticamente do que a barra de ferramentas mostra.

Cole um workflow ou carregue o exemplo

Cole o workflow YAML copiado do seu editor, ou carregue o exemplo embutido — ele já traz um gatilho schedule, um job com strategy.matrix e referências env/secrets/github, para ver as cinco funcionalidades de uma vez. A validação automática vem ligada por padrão e roda de novo 350ms depois que você para de digitar; nada é enviado.

Clique em qualquer nome de job ou step na árvore de navegação e o editor pula direto para aquela linha — é aí que realmente economiza tempo quando o workflow passa de alguns jobs.

Trate os painéis de matrix e cron como rascunhos, não como edição ao vivo

Editar a tabela de variáveis do matrix ou os campos de cron nunca altera o workflow sozinho, só gera uma pré-visualização. Nada é escrito em strategy.matrix ou on.schedule até clicar em Inserir, e até lá o rascunho ainda pode ser copiado separadamente.

Coloque números de versão entre aspas, como node-version: "3.10" — sem aspas, o YAML lê 3.10 como o número 3.1 e perde o zero final silenciosamente.
fail-fast vem como true por padrão e max-parallel fica vazio (sem limite), igual ao padrão do próprio GitHub Actions.

Leia os avisos de risco antes de confiar num resultado limpo

A lista de referências env/secrets/vars/github marca exatamente os pontos em que o GitHub Actions é documentado como rejeitando a expressão, não é um palpite de linter genérico. Ctrl/Cmd+Enter roda a validação de novo quando a execução automática está desligada; se você continuar editando depois de um resultado, copiar e baixar ficam desativados até revalidar, para nunca exportar algo desatualizado.

Um filtro acima da lista de referências mostra só env, secrets, vars ou github por vez, útil quando o workflow tem muitas expressões.

O que realmente acontece por trás

Cinco funcionalidades que trabalham juntas em vez de cinco abas separadas.

Formatação de YAML com indentação à sua escolha

Reformata um workflow com indentação consistente de dois ou quatro espaços, para que o diff de um pull request mostre só as linhas que realmente mudaram, não o arquivo inteiro reformatado.

Verificações estruturais contra as regras reais do workflow

Os ids de job e step são verificados contra o padrão de nomenclatura exigido, cada job é confirmado com runs-on ou uses, os valores de permissions são comparados com a enumeração real, e filtros mutuamente exclusivos como branches e branches-ignore são sinalizados quando aparecem juntos no mesmo gatilho.

Árvore de navegação job/step clicável

A árvore reflete a estrutura real de jobs e steps do workflow; selecionar um item rola o editor até aquela linha exata, sem precisar contar níveis de indentação na mão.

Gerador de matrix com include, exclude e fail-fast

Monte uma tabela de variáveis do tipo os/versão, adicione combinações include ou exclude, ajuste fail-fast e max-parallel, pré-visualize o strategy.matrix resultante e insira no job escolhido.

Inventário de referências env/secrets/vars/github

Cada expressão ${{ }} que referencia env, secrets, vars ou github é extraída e listada por job e step, com um filtro para isolar apenas um desses contextos por vez.

Gerador de trechos cron feito para o GitHub Actions

Monte um agendamento de cinco campos a partir de presets comuns ou de uma expressão personalizada, pré-visualize a entrada exata de on.schedule e insira — os limites de agendamento do próprio GitHub são aplicados automaticamente, sem precisar decorar.

O que esta ferramenta verifica, e o que deixa de fora de propósito

Conhecer os limites importa mais do que uma lista longa de funcionalidades.

Nada se conecta ao GitHub: Este validador GitHub Actions só lê YAML localmente. Nunca chama a API do GitHub, nunca faz fork ou push de um repositório, e nunca dispara ou executa um workflow — ele apenas formata e verifica o texto colado, inteiramente no seu dispositivo.
Expressões não são avaliadas: ${{ github.sha }} ou ${{ steps.build.outputs.version }} são extraídas e listadas, mas não resolvidas para um valor real de execução. Testar o comportamento real das expressões exige um motor dedicado, que é uma ferramenta separada — esta não finge isso com um eval de JavaScript.
A checagem de schema é um subconjunto focado, não é o actionlint: A validação estrutural cobre a parte do schema público do schemastore.org que não depende de metadados externos: id de job/step, runs-on/uses, permissions, conflitos de filtros. Não verifica tipos de input de uma action, versões de actions do Marketplace, nem mantém uma lista atualizada de labels de runner suportados, porque esses metadados ficam desatualizados assim que são armazenados offline.
Sem grafo de dependências: A árvore job/step mostra estrutura, não um DAG renderizado das relações needs: entre jobs. Para ver esse grafo de dependências visualmente é preciso outro tipo de visualização, que esta ferramenta ainda não oferece.
Os limites de agendamento são documentados, não garantidos: O gerador de cron aplica as regras publicadas pelo GitHub — mínimo de cinco minutos, UTC por padrão, sem aliases como @daily —, mas não pode garantir que o campo timezone opcional seja respeitado, nem que um agendamento dispare exatamente no minuto certo; o próprio GitHub avisa que execuções podem atrasar sob carga alta e são desativadas após 60 dias de inatividade do repositório.

Perguntas frequentes sobre o validador GitHub Actions

Respostas baseadas no que o GitHub documenta, não em suposições.

O timezone configurado num agendamento cron do GitHub Actions realmente funciona?

O que é gerado está sintaticamente correto — o GitHub Actions adicionou suporte opcional a fuso horário IANA no schedule em 2024. Mas as próprias discussões da comunidade do GitHub trazem relatos reais de que ele não foi respeitado. Este validador só garante que o trecho corresponde à sintaxe publicada, não que o agendador do GitHub realmente a aplique.

Por que meu agendamento cron do GitHub Actions não executa no horário definido?

Algumas causas reais: o arquivo workflow não está na branch padrão, o repositório ficou inativo e o GitHub desativou o agendamento automaticamente depois de 60 dias, ou a expressão usa um intervalo menor que o mínimo documentado de cinco minutos. O GitHub também avisa que execuções agendadas podem atrasar em períodos de carga alta, especialmente perto das horas cheias — esta ferramenta valida a sintaxe do cron, mas não garante o horário exato de disparo.

O GitHub só mostra "you have an error in your yaml syntax" mas não diz a linha certa, como encontrar?

Cole o workflow neste validador GitHub Actions: ele mostra o nome exato do job ou step junto com a linha e a coluna, em vez da mensagem genérica do GitHub. A validação automática roda de novo 350ms depois que você para de digitar, então o ponto marcado se atualiza enquanto você corrige.

Por que o bloco with: de um reusable workflow mostra "Unrecognized named-value: 'env'"?

Porque o contexto env simplesmente não está disponível dentro de with: — uma das três restrições documentadas que o painel de referências sinaliza diretamente (env também não é permitido no id nem no uses de um step). Mova o valor para um env no nível do job ou do workflow, ou passe explicitamente como input para o reusable workflow.

Como usar um secret do GitHub Actions dentro de um if?

Não diretamente: secrets não pode ser lido dentro de uma condição if:. Primeiro atribua o secret a uma variável env no nível do job ou do step, e depois teste esse valor de env na condição if:. Esse é um dos três pontos de risco que o painel de referências destaca para cada referência secrets.*.

Por que o número de versão matrix 3.10 vira 3.1?

Um 3.10 sem aspas é lido pelo YAML como o número 3.1, perdendo o zero final silenciosamente — é uma peculiaridade do parsing do YAML, não um bug do GitHub Actions. O gerador de matrix detecta valores com cara de versão e coloca aspas automaticamente ao inserir o strategy.matrix gerado.

Encontrou um workflow que esta ferramenta avalia errado?

Experimente este validador GitHub Actions agora

Cole um workflow neste validador GitHub Actions, veja a árvore job/step e a lista de referências se atualizarem, e prepare um rascunho de matrix ou cron quando precisar.

Tudo fica no seu navegador — nada é enviado, e nenhum workflow é disparado.

Voltar para a ferramenta Ver ferramentas de CI/CD

Toda a análise acontece localmente no seu navegador.

validador GitHub Actionsformate, valide e navegue por cada job