/ci-audit — Encontre e corrija tempo desperdiçado no GitHub Actions
Meça primeiro, depois corrija as poucas coisas que realmente importam. Em auditorias reais, a maior vitória raramente foi um conjunto de testes lento. Foi um pipeline agendado que falhou todos os dias durante meses, um cron de 30 segundos a cada hora faturado como 730 minutos por mês, ou um SDK que tentava silenciosamente uma requisição morta três vezes.
Um script stdlib, scripts/ci_audit.py na pasta deste skill, faz a medição. Você lê sua saída, decide o que vale a pena corrigir e envia as correções.
python3 <diretorio-do-skill>/scripts/ci_audit.py inventory <proprietario> # quais repositórios executam Actions, privados vs públicos
python3 <diretorio-do-skill>/scripts/ci_audit.py month <proprietario/repo> # minutos faturáveis por workflow, 30 dias
python3 <diretorio-do-skill>/scripts/ci_audit.py jobs <proprietario/repo> --runs 150 # fila / setup / execução por job
python3 <diretorio-do-skill>/scripts/ci_audit.py steps <proprietario/repo> <run-id> # segundos por passo para uma execução
python3 <diretorio-do-skill>/scripts/ci_audit.py schedules <proprietario/repo> # cada cron como execuções por mês
Ele precisa da CLI do GitHub (gh) logada. month e jobs fazem uma chamada à API por execução, então um repositório movimentado leva um ou dois minutos. Execute-os em segundo plano.
Passo 0 — Escopo e regras
Antes de medir, alinhe com o usuário:
- Quais proprietários e repositórios. Um repositório, ou tudo que foi enviado nos últimos 60 dias.
- Repositórios proibidos. Alguém (um colega, outro agente) está no meio de uma funcionalidade lá. Esses recebem uma issue com números, nunca um branch enviado.
- Para onde os merges vão. O branch de integração (
development, por exemplo) por padrão. Publicar no branch padrão é um sim separado, mas crons e correções agendadas só entram em vigor depois dele (Passo 6). - O que está fora do escopo: reduzir cobertura de testes, runners pagos, trocar de fornecedor de CI. Recomende esses com números; não os execute.
Leia references/gotchas.md agora.
Passo 1 — Inventário e dinheiro
ci_audit.py inventory <proprietario>para cada proprietário. Anote privado vs público: apenas repositórios privados custam dinheiro, mas o tempo de espera de cada repositório importa quando agentes bloqueiam no CI.- Para uma organização, obtenha a fatura real:
gh api "/organizations/<org>/settings/billing/usage?year=YYYY&month=M". Para uma conta pessoal, useci_audit.py monthem cada repositório privado e compare o total com os minutos incluídos no plano. - Anote os 5 principais repositórios por minutos faturáveis. É aí que o tempo é gasto.
Passo 2 — Quebrado antes de lento
Para cada repositório com workflows agendados:
- Verifique as últimas 10 execuções agendadas por workflow. Qualquer workflow que falhe sempre é o primeiro achado, independentemente do custo. Leia seus logs (
gh api repos/O/R/actions/runs/<id>/logs > logs.zip). - Execute
actionlintem.github/workflows/. Um arquivo que o GitHub não consegue analisar nunca executa sua agenda.
Espere erros em camadas. Veja references/fixes.md §1.
Passo 3 — Agendamentos
ci_audit.py schedules <repositorio> em cada repositório com crons. Multiplique execuções/mês pelos minutos faturados por execução (de jobs). Sinalize:
- Jobs curtos em cronogramas apertados (uma verificação de 30 segundos a cada hora é 730 min faturados/mês).
- Vários crons no mesmo minuto que atingem a mesma API com limite de taxa.
- Crons mensais que fazem uma execução enorme. Divida o trabalho ao longo de noites.
Passo 4 — Detalhamento por job
Para os principais repositórios: ci_audit.py jobs <repositorio> --runs 150, depois steps em uma execução verde recente de cada job caro. Classifique o tempo de cada job:
| Categoria | O que indica |
|---|---|
| Fila alta | Contenção de runners ou grupos de concorrência. Geralmente não é corrigível de forma barata; anote. |
| Setup alto | Instalação de dependências e cache (references/fixes.md §3–4). |
| Execução alta, testes do app | Tempo real de teste. Deixe como está, a menos que um passo seja claramente redundante. |
| Execução alta, pipeline de dados | Instrumente fases e corrija o código, não o CI (references/fixes.md §6). |
| Falhas > 5% | Testes instáveis ou pipelines quebrados (references/fixes.md §1, §7). |
Passo 5 — Relatório e escolha
Escreva uma tabela, ordenada por minutos estimados economizados por mês:
| Repositório | Achado | Evidência | Correção | Est. economia/mês | Risco |
|---|
Inclua achados que você não corrigirá (repositórios proibidos, decisões do proprietário como frequência de cron ou paralelismo) com os números que o proprietário precisa para decidir. Mostre ao usuário e obtenha aprovação sobre quais linhas enviar. Arquivar como ${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/ci-audit/archive/<YYYY-MM-DD>-<escopo>.md.
Passo 6 — Rodada de correções
Um repositório, um worker. Em hosts que suportam subagentes, execute repositórios em paralelo com o mesmo briefing: clone fresco, issue primeiro, branch nomeado com base na issue, commits pequenos, números de antes/depois no corpo do PR.
Para cada correção:
- Abra uma issue com a medição.
- Faça a alteração em um branch. Execute lint e testes localmente, confirmando pelo código de saída.
- Prove: envie, depois re-execute o CI do PR para que o cache esteja quente, e compare com uma linha de base de várias execuções antigas. Para correções de pipeline, dispare o workflow a partir do branch com um limite pequeno.
- Se a alteração não ajudou (acontece, por exemplo, caches do Playwright), feche o PR com os números. Isso é um resultado, não uma falha.
- Faça merge no branch de integração após revisão e verificações verdes.
- Para qualquer coisa agendada, abra o PR de lançamento para o branch padrão assim que o usuário concordar. Até lá, nada muda em produção.
Passo 7 — Verifique e registre
- Após a próxima execução agendada, leia seus tempos e logs. Confirme que a correção se manteve em produção, não apenas no branch.
- Anexe resultados ao arquivo de arquivo: antes/depois por repositório, o que foi fechado sem merge e novos imprevistos.
- Sugira reexecutar a auditoria mensalmente, ou sempre que o CI parecer lento. Um lembrete recorrente (
loopify) funciona bem.
Compõe com
loopify— agende uma reauditoria mensal ou uma verificação na manhã seguinte da primeira execução agendada.castmate— obtenha a revisão de um segundo modelo em uma alteração de workflow arriscada.unstuck— quando uma correção que deveria funcionar mede mais devagar, antes de desistir dela.project-manager— acompanhe decisões do proprietário (frequência de cron, runners pagos) que a auditoria revelou mas não implementou.
Notas sobre qualidade
- Quebrado supera lento. Sempre verifique workflows agendados com falha antes de cronometrar qualquer coisa. Um pipeline diário falhando por seis meses é uma perda maior do que qualquer cache.
- Números quentes ou nenhuma afirmação. Nunca relate uma aceleração a partir de uma execução fria. Reexecute, use como linha de base várias execuções antigas e mencione ambos os números no PR.
- Minutos faturados, não segundos. Arredondamento por job significa que menos jobs mais completos superam muitos pequenos em repositórios privados. Paralelizar é uma decisão de velocidade com custo, não uma vitória gratuita.
- Mesma cobertura, sempre. A contagem de testes antes e depois vai no corpo do PR. Um conjunto mais rápido que testa menos não é uma correção.
- Agendado significa branch padrão. Não considere uma correção de cron ou pipeline concluída até que esteja no branch padrão e uma execução agendada tenha passado.
- Feche experimentos fracassados com dados. Um PR que ficou mais lento é fechado com seus números, para que ninguém tente a mesma ideia no próximo trimestre.
- Respeite branches de outras pessoas. Repositórios proibidos recebem issues, nunca pushes.