Os gatilhos

Um workflow declarado com on: push roda a cada push, em cada branch, inclusive quando o commit altera apenas o arquivo README.md. Em uma equipe de cinco pessoas, isso rapidamente chega a várias centenas de execuções por semana, a maioria delas sem verificar nada de útil. O problema não é apenas o custo em minutos faturados: é a fila de espera. Quando vinte execuções inúteis ocupam os runners, aquela que bloqueia um merge urgente fica esperando atrás delas.

O caso mais custoso é mais discreto. Você faz push de três commits seguidos em uma branch de trabalho — uma correção, um esquecimento, um erro de digitação. O GitHub dispara três execuções completas em paralelo, e as duas primeiras testam um estado do código que ninguém jamais vai fazer merge. Elas vão rodar até o fim, ocupar runners, e seu resultado será ignorado. Escolher bem seus gatilhos e saber cancelar é o que separa uma esteira rápida de uma esteira que acaba sendo contornada.

push e pull_request: a duplicidade clássica

Esses dois eventos se parecem, mas não testam a mesma coisa. push testa o conteúdo da branch tal como ele está. pull_request testa, por padrão, um merge simulado entre a branch de origem e a branch de destino — um commit de merge efêmero que não existe em nenhum repositório. É exatamente o estado que importa antes de um merge, e é isso que permite detectar um conflito semântico: duas alterações válidas separadamente, mas incompatíveis juntas.