Eficiência do GitHub Actions

Use esta habilidade como um ponto de entrada enxuto para trabalhos de eficiência do GitHub Actions. Inspecione o repositório, identifique a fonte de desperdício e carregue apenas o material de referência necessário para a tarefa atual.

Se ainda não existirem fluxos de trabalho, carregue references/actions.md e defina uma linha de base antes de prosseguir com as etapas abaixo.

Se o acesso ao shell ou à CLI gh não estiver disponível: peça ao usuário para colar o conteúdo de .github/workflows/ e a saída de gh run list --limit 10. Se apenas arquivos parciais forem fornecidos, anote: "Auditoria baseada apenas nos arquivos fornecidos; alguns insights podem estar incompletos." Comece as respostas apenas com arquivos com: "Análise estática (não confirmada com execuções ao vivo)."

Use Esta Habilidade Quando

• O usuário deseja reduzir o tempo de execução do GitHub Actions, o custo de CI ou execuções de fluxo de trabalho desperdiçadas.
• O repositório possui fluxos de trabalho existentes em .github/workflows/ ou perguntas explícitas de configuração do GitHub Actions.
• O usuário pergunta sobre cache, concorrência, filtros de caminho, redução de matriz, otimização de jobs ou correções específicas de fluxo de trabalho.
• O usuário precisa de ajuda para criar um novo fluxo de trabalho do GitHub Actions ou uma linha de base de CI do zero.

Carregue Apenas o Que Você Precisa

• references/actions.md — auditorias, controle de jobs, redução de matriz, validação ao vivo e correções específicas de fluxo de trabalho.
• references/reporting.md — quando o usuário solicitar um relatório de eficiência antes/depois.
• references/patterns.md — exemplos completos de YAML quando os comandos de auditoria inline não forem suficientes.

Fluxo de Trabalho Principal

1. Meça primeiro

rg -n "on:|concurrency:|paths:|paths-ignore:|strategy:|matrix:|cache:" .github/workflows
gh run list --limit 10
run_id=$(gh run list --limit 1 --json databaseId --jq '.[0].databaseId')
gh run view "$run_id" --log-failed

Procure por: caches de dependência ausentes, cancelamento de concurrency ausente, gatilhos excessivamente amplos, cobertura duplicada de fluxo de trabalho e jobs caros que rodam a cada alteração, independentemente do escopo.

2. Aplique barreiras de proteção

Verifique cada correção proposta contra estas regras antes de recomendá-la:

1. Não oculta validação necessária — descarte qualquer correção que remova verificações de release, schema, migração ou bibliotecas compartilhadas.
2. Não reduz o paralelismo sem justificativa — descarte, a menos que o usuário priorize o custo sobre a latência e o novo caminho crítico permaneça dentro de 1,25x do original.
3. Preserva apenas "legs" de matriz documentados — descarte "legs" de matriz sem compromisso explícito de versão ou plataforma.
4. Jobs de escrita usam gatilhos opt-in — sinalize (não descarte) jobs de formatação ou bots que rodam automaticamente; recomende um gatilho opt-in em vez disso.
5. Alterações de repositório permanecem separadas das configurações de organização — divida qualquer correção que misture YAML editável pelo repositório com configurações de nível de organização ou conta GitHub em duas recomendações distintas.

3. Selecione as 3 principais correções

Das seis candidatas abaixo, mantenha apenas aquelas suportadas por evidências de auditoria da etapa 1 e que passem por todas as barreiras de proteção da etapa 2. Classifique as sobreviventes pela economia estimada de minutos de CI diários (economia por execução × execuções por dia). Selecione todas as candidatas que atendam a ambos os critérios, até um máximo de 3.

1. Adicionar cache de dependência com chaves baseadas em lockfile
2. Adicionar ou corrigir cancelamento de concurrency
3. Remover cobertura duplicada de fluxo de trabalho antes de mesclar jobs
4. Estreitar gatilhos de fluxo de trabalho ou job com segurança
5. Reduzir a amplitude da matriz para corresponder ao risco e tipo de evento
6. Paralelizar jobs independentes no caminho crítico

4. Verifique

• Se o acesso à CLI gh estiver disponível, valide o controle de caminho e o cancelamento de concorrência com um push de teste ao vivo em um branch não protegido.
• Se a validação ao vivo não for possível, declare isso explicitamente na saída.
• Trate o comportamento inesperado ao vivo como um bug real, mesmo quando o YAML parecer correto.

Saída Necessária

1. Fontes de desperdício — principais impulsionadores de custo ou latência encontrados na etapa 1
2. Correções propostas — as 3 principais (ou todas as restantes) com evidências de auditoria de suporte
3. Validação — o que foi comprovado ao vivo, o que foi verificado apenas localmente e qualquer risco restante
4. Impacto — economia esperada vs. economia medida; separe o tempo de parede do PR do tempo total do runner

Referências

• references/actions.md
• references/reporting.md
• references/patterns.md
• references/review-rubric.md — carregar ao revisar o trabalho de eficiência concluído