Conceito e mecanismo
Um workflow combina eventos, condições e jobs. Antes de investigar o runner, confirma se o evento devia criar uma execução: um ficheiro com workflow_dispatch precisa de existir na default branch; filtros simultâneos de branch e paths precisam de corresponder. Um cron declara intenção de agendamento, não um compromisso de conclusão. Regista o horário esperado, a execução observada e o resultado de negócio. Um push feito com GITHUB_TOKEN normalmente não desencadeia outro workflow; os eventos de dispatch têm exceções documentadas. Esta proteção contra recursão deve ser considerada ao desenhar cadeias de automação, em vez de acrescentar uma credencial ampla sem avaliar a necessidade.
Aplicação guiada
Num controlo fictício de abertura diária, distingue execução ausente, execução em fila e controlo concluído com erro. Cada estado pede evidência diferente. Se o controlo não arrancou, verifica evento e configuração; se está em fila, verifica elegibilidade e capacidade; se falhou, examina o primeiro erro útil. Needs estabelece dependências entre jobs, sem partilhar automaticamente a máquina ou o ambiente. Uma dependência falhada pode deixar o relatório skipped quando não há condição de estado explícita. Para recolher todos os resultados de uma matrix, considera fail-fast: false e conserva as falhas como resultados reais. Antes de repetir operações com efeitos externos, confirma idempotência e decide quem comunica o risco ao prazo.
build falha; report com needs: build fica skipped. A ausência de relatório não demonstra sucesso.
Armadilhas comuns
Cron como SLA; branch ou path como OR; needs como memória partilhada; tolerar erro como recolher evidência.
Tópicos relacionados: Dados, outputs e rede dos services · Reutilização, artifacts e diagnóstico · Actions com contratos e versões
Segue a cadeia evento, seleção, dependências, execução e resultado.
Referência: Workflow events · GH-200 skills measured January2026;study guide updated2026-02-05