GitHub Actions vai apagar checks e runs mais cedo: revise a retenção antes de outubro

Ferramentas · "Loop"

A configuração de retenção do GitHub Actions vai passar a valer para mais do que artefatos e logs. A partir de 1º de outubro de 2026, checks, workflow runs e commit statuses também serão removidos quando ultrapassarem o período definido no repositório, na organização ou na empresa.

Hoje, esses metadados ficam disponíveis por mais de 400 dias independentemente da retenção configurada para Actions. O padrão mais comum é 90 dias. Para equipes que usam o histórico da interface como arquivo de auditoria ou voltam a uma execução antiga para investigar incidentes, a diferença é grande.

O que entra na nova regra

  • workflow runs, a execução de um workflow disparada por push, pull request, agendamento ou outro evento;
  • checks, os resultados associados a jobs e integrações exibidos em commits e pull requests;
  • commit statuses, os estados usados por integrações e regras de proteção de branch;
  • artefatos e logs, que já seguiam a configuração existente.

O GitHub fará a limpeza automática quando os itens passarem do prazo. Repositórios públicos continuam limitados a no máximo 90 dias. Em organizações e empresas, políticas superiores podem limitar o valor escolhido pelo repositório.

Há um ponto sem botão de desfazer: aumentar a retenção depois não recupera dados já removidos. Por isso a revisão precisa acontecer antes que o novo comportamento comece.

O impacto não é só perder o log

Uma execução antiga pode registrar qual commit foi implantado, quais jobs passaram, quem disparou o workflow e quanto tempo cada etapa levou. Checks ajudam a reconstruir a decisão de merge. Statuses podem fazer parte da evidência de que uma política foi aplicada.

Se outra plataforma já recebe dados de deploy, segurança e auditoria, o GitHub talvez não seja a fonte histórica principal. Se não recebe, a equipe pode descobrir em outubro que sua “retenção de CI” era apenas a permanência acidental da interface.

Aumentar o prazo também tem custo

Checks, runs e statuses não são cobrados como armazenamento. Artefatos e logs, porém, entram na conta. Como todos passam a compartilhar a mesma configuração geral, aumentar a retenção para preservar metadados pode também manter arquivos pesados por mais tempo e elevar o uso faturável.

É aqui que uma escolha única pode ser grosseira para necessidades diferentes. Um binário de teste descartável talvez não mereça 180 dias; a evidência de uma implantação em produção talvez mereça anos. O campo retention-days da action de upload permite reduzir a vida de artefatos específicos, respeitando o limite definido pelo repositório ou pela organização.

- uses: actions/upload-artifact@v4
  with:
    name: relatorio-testes
    path: reports/
    retention-days: 14

Assim, a configuração geral pode preservar o histórico necessário enquanto artefatos volumosos e de baixo valor expiram antes.

O que revisar antes de 1º de outubro

  • descubra o prazo atual em repositórios, organizações e empresas;
  • identifique auditorias, incidentes e deploys que consultam runs antigos;
  • confira se branch protection depende de checks que podem ser arquivados;
  • exporte dados que precisem viver além do limite permitido;
  • reduza individualmente a retenção de artefatos grandes e temporários;
  • documente onde ficará a fonte de verdade histórica do CI/CD.

A API REST permite listar workflow runs e filtrar por data, branch, evento, status ou commit. Ela pode ajudar num inventário ou numa exportação, mas não deve ser tratada como backup depois que a retenção já venceu. Para histórico de longo prazo, copie o conjunto mínimo necessário para um armazenamento com política própria e dados sensíveis protegidos.

A mudança torna a configuração mais coerente: um prazo de Actions passa a alcançar o histórico de Actions. O trabalho agora é verificar se a organização usava aqueles 400 dias sem perceber. Retenção só parece detalhe até o dia em que a pergunta do incidente está numa execução que já sumiu.

Fontes