Teste suas condições if: e seus triggers antes de fazer push.

Ele tem duas abas. O Avaliador de Expressões roda as suas expressões ${{ }} contra um contexto fictício editável (github, env, matrix, steps, needs) usando a semântica exata do GitHub Actions — os operadores, o == de strings que ignora maiúsculas e minúsculas, as regras de coerção parecidas com as do JS e funções documentadas como contains, startsWith, endsWith, format, join, toJSON, fromJSON, success(), failure(), always() e cancelled(). O Simulador de Triggers permite que você descreva um evento de push, pull_request ou tag e mostra uma tabela RUN ou SKIPPED por job que explica exatamente qual filtro on:, branches, tags, paths ou paths-ignore decidiu o resultado. Juntos, eles respondem "este if: vai ser verdadeiro?" e "este workflow vai sequer disparar?" antes de você fazer o push.

Quase sempre porque o if: contém texto literal fora de ${{ }} — por exemplo if: "${{ github.event_name }}" == 'push' ou if: always-deploy. O GitHub não avalia a linha inteira como uma única expressão; os caracteres literais transformam a condição em uma string não vazia, e uma string não vazia é truthy, então o passo roda toda vez. Envolva a condição inteira em um único ${{ }} (por exemplo if: ${{ github.event_name == 'push' }}) e o Avaliador de Expressões vai sinalizar a armadilha (actions/runner#1173) e mostrar o resultado corrigido, truthy ou falsy.

Cole a expressão na aba do Avaliador de Expressões e edite o contexto fictício github/env/matrix/steps/needs para corresponder à execução que lhe interessa — sem commit, sem push, sem esperar por um runner. Você recebe o valor avaliado na hora, além de um aviso caso a sintaxe fosse silenciosamente coergida para sempre verdadeira. É a maneira mais rápida de verificar uma condição if: ou uma interpolação ${{ }} antes que ela chegue ao GitHub Actions.

Essas são funções de verificação de status que você usa em um if:. success() é verdadeira apenas quando todos os passos anteriores ou jobs necessários tiveram sucesso (é o padrão implícito no momento em que você não escreve nenhum if:), failure() é verdadeira quando algum deles falhou, cancelled() é verdadeira quando o workflow foi cancelado, e always() força o passo a rodar independentemente do status anterior — inclusive em caso de cancelamento. O detalhe é que escrever qualquer if: personalizado remove a proteção implícita de success(), então if: env.DEPLOY == 'true' vai rodar mesmo depois que um passo anterior falhou, a menos que você adicione && success(). O avaliador permite que você alterne o status fictício e veja cada função ser resolvida.

As causas usuais são uma ref que não corresponde ao glob de on: branches ou tags, o arquivo de workflow ainda não existir na branch de destino, ou um filtro de paths excluindo todos os arquivos alterados. Uma sutil: quando você define tanto branches quanto paths sob o mesmo evento, eles se combinam com AND — o evento precisa corresponder a ambos, não a um ou outro. Descreva o seu evento no Simulador de Triggers e ele reproduz os filtros on: e diz o motivo decisivo para cada job.

Dentro de um único evento, branches (ou tags) e paths são combinados com AND: um push precisa estar em uma branch que corresponda e tocar em um path que corresponda para o workflow rodar. Dentro de um único filtro, os padrões são combinados com OR — qualquer um glob de branch ou qualquer um path alterado que corresponda já é suficiente. O Simulador de Triggers torna isso explícito ao mostrar separadamente a decisão de branch e a decisão de path, e em seguida o veredito combinado RUN ou SKIPPED.

* corresponde a quaisquer caracteres exceto o separador de caminho /, enquanto ** corresponde através dos separadores, incluindo o /, então feature/** corresponde a feature/a/b mas feature/* corresponde apenas a feature/a. O motor de glob também respeita +, ?, a negação ! e o escape \ da mesma forma que o GitHub faz. O Simulador de Triggers usa uma reimplementação fiel dessas regras para que você possa testar um padrão como 'release/**' ou '!**/*.md' contra uma ref ou lista de arquivos reais e ver o que corresponde.

No Simulador de Triggers você fornece o tipo de evento, o nome da ref e a lista de arquivos alterados; a ferramenta então avalia os filtros on: de cada job e qualquer if: no nível do job contra esse evento simulado e renderiza uma linha RUN ou SKIPPED com o motivo decisivo — "branch correspondeu mas o path não", "sem filtro de paths", "if: avaliado como falso" e assim por diante. Ela espelha a ordem de decisão do GitHub Actions em vez de adivinhar, então o veredito corresponde ao que o runner real faria para aquele evento.

O actionlint é um linter estático para a sintaxe de workflows e a tipagem de expressões, e o act de fato executa os seus jobs em containers Docker locais — ambos são ótimos e valem a pena usar. Esta ferramenta não faz nenhum dos dois: ela não roda os seus passos e não é um verificador de tipos. É um playground de semântica que avalia uma única expressão ${{ }} ou simula a filtragem de triggers contra um contexto que você controla, no navegador, para que você possa raciocinar sobre por que um if: é truthy ou por que um workflow disparou ou não, sem subir containers nem fazer commits.

Qualquer coisa que dependa do estado real do runner. hashFiles() precisa dos arquivos reais em disco, então o avaliador o trata como um placeholder opaco em vez de calcular um hash verdadeiro; o payload completo do webhook é muito maior do que o contexto github fictício que expomos; e o conteúdo ao vivo das ações, os secrets e os labels do runner não são resolvidos. Trate um resultado limpo como uma forte confiança antes do push sobre a lógica de expressões e triggers — não como uma garantia sobre o hashing de arquivos ou o payload completo do evento.

Não. As duas abas rodam 100% no lado do cliente. As expressões, o contexto fictício, os filtros do workflow e os payloads de eventos que você insere são avaliados dentro da aba do seu navegador — nada é enviado, não há conta e não há cadastro. Você pode colar com segurança workflows internos ou proprietários, inclusive nomes de secrets, labels de runners privados e listas reais de branches e paths.

Não. Esta é uma ferramenta independente e comunitária, e não é afiliada, endossada nem patrocinada pela GitHub, Inc. "GitHub" e "GitHub Actions" são usados aqui apenas de forma descritiva, para identificar o formato de expressões e triggers de workflow que a ferramenta avalia.