O GitHub anunciou nesta quinta-feira (27) que passará a apagar verificações, execuções e status antigos de acordo com o prazo de retenção configurado para cada projeto. A regra entra em vigor em 1º de outubro de 2026 e usa 90 dias como período padrão.
A mudança afeta o GitHub Actions, serviço que executa tarefas automáticas ligadas ao código, como testes, compilações e publicação de aplicativos. Até agora, os três tipos de registro atingidos pelo anúncio permaneciam guardados por mais de 400 dias, mesmo quando artefatos e registros detalhados eram removidos antes.
O anúncio do GitHub confirma que verificações, execuções e status passarão a seguir o prazo do Actions em 1º de outubro. A documentação do serviço detalha os limites atuais para artefatos e logs, enquanto o RunxBuild explica de forma independente como esses registros eram separados antes da mudança.
Na prática, uma equipe que mantém a configuração padrão poderá deixar de encontrar na interface uma execução concluída há mais de três meses. Quem depende de um histórico maior precisa revisar o ajuste antes da data e exportar o material que não pode desaparecer.
O GitHub diz que a limpeza abrangerá checks, workflow runs e statuses. Checks são verificações como testes e análise de código; workflow run é cada execução de uma sequência automatizada; status é o resultado associado a uma alteração, como sucesso, falha ou tarefa em andamento.
Um ajuste passa a controlar cinco registros
A configuração já define por quanto tempo artefatos e logs ficam disponíveis. Artefatos são arquivos produzidos pela automação, como um aplicativo compilado ou um relatório de testes, enquanto logs são os registros de texto que mostram o que cada etapa fez.
A partir de outubro, o mesmo número de dias também valerá para verificações, execuções e status. O nome exibido na interface será atualizado para indicar que a retenção cobre os cinco itens, reduzindo a diferença entre o prazo do arquivo gerado e o prazo da página que documenta sua execução.
O ajuste pode existir no repositório, a pasta central que guarda o projeto e seu histórico, ou ser herdado de uma organização e de uma conta empresarial. Um administrador não consegue ultrapassar o limite definido no nível superior.
Para repositórios públicos, o comunicado estabelece máximo de 90 dias para verificações, execuções e status, igual ao limite que já vale para artefatos e logs. A documentação atual permite configurar os arquivos de projetos públicos entre 1 e 90 dias.
Em repositórios privados, a documentação do GitHub permite manter artefatos e logs entre 1 e 400 dias. O anúncio orienta respeitar os limites da organização e da empresa, por isso a opção efetivamente disponível precisa ser conferida na conta que administra o projeto.
A limpeza será automática quando um item ultrapassar o prazo escolhido. Para a maioria das equipes, segundo o GitHub, não será preciso apertar um botão em outubro porque o serviço usará a configuração que já estiver salva.
O histórico longo deixa de ser garantido
O contraste mais importante está no tempo de permanência. Uma execução podia perder seus arquivos e o texto detalhado depois de 90 dias, mas verificações, status e outros dados continuavam visíveis por mais de 400 dias.
Com a nova regra, essa camada de histórico também seguirá o período configurado. Um projeto com retenção de 30 dias, por exemplo, não deve contar com a página de uma execução antiga disponível no GitHub depois que ela ultrapassar esse limite.
Projetos sujeitos a auditoria também precisam separar o histórico do código do histórico operacional. O Git mantém as alterações e seus autores, mas o GitHub Actions guarda informações adicionais sobre quem iniciou uma automação, quando ela rodou e qual foi o resultado.
O anúncio recomenda exportar ou arquivar tudo o que precise permanecer além do prazo. O GitHub não apresenta nessa nota uma ferramenta nova de arquivo permanente, então cada equipe deve escolher um destino compatível com suas exigências de segurança, privacidade e acesso.
A mudança não recupera o que já sumiu
O GitHub ressalta que aumentar o prazo não traz de volta dados removidos por uma política anterior. Se um artefato, log ou outro registro já foi apagado, salvar um número maior na configuração não reconstrói o arquivo.
Por isso, revisar o ajuste perto do prazo não substitui uma cópia antecipada. A equipe precisa identificar quais execuções antigas sustentam uma auditoria, uma entrega a cliente ou a reprodução de um erro e preservá-las enquanto ainda podem ser consultadas.
A expressão usada pelo GitHub para dizer que a mudança não é retroativa se refere especialmente a essa impossibilidade de restaurar material eliminado. Ela não deve ser lida como promessa de que todo histórico criado antes de outubro ficará guardado para sempre.
Quando a regra começar, itens que já estiverem além do período configurado poderão entrar na limpeza. O comunicado não informa um calendário por conta nem promete uma fila de aviso individual para cada execução prestes a desaparecer.
Arquivos cobrados e metadados seguem regras diferentes
Artefatos e logs contam para o armazenamento cobrado do GitHub Actions. Verificações, dados da execução e status não geram cobrança própria de armazenamento, de acordo com o comunicado, embora apontem para arquivos que podem ocupar espaço.
Reduzir o prazo remove artefatos e logs mais cedo e pode diminuir a conta de armazenamento. Aumentá-lo preserva mais material, mas também pode elevar o custo quando o uso ultrapassa a franquia incluída no plano.
Também não basta alterar individualmente o prazo de um artefato enviado por uma automação. O parâmetro retention-days, usado no arquivo de configuração para escolher quantos dias um artefato ficará guardado, não controla sozinho logs, verificações, execuções e status.
O período geral deve ser revisto nas configurações do Actions no repositório, na organização ou na empresa. Se houver limites herdados, o administrador do projeto pode enxergar um valor máximo menor do que esperava.
Projetos públicos ficam limitados a 90 dias
O teto de 90 dias para repositórios públicos merece atenção porque muitos projetos abertos usam a página do Actions como registro de testes e lançamentos. Depois da mudança, uma pessoa que chegar meses mais tarde poderá não encontrar a execução vinculada a uma versão antiga.
O código, as versões publicadas e os pedidos de revisão não são anunciados como alvos dessa limpeza. O que muda é o conjunto de dados do Actions que documenta as verificações e as execuções automáticas.
Um pedido de revisão, a área em que uma alteração é analisada antes de entrar no projeto, pode continuar existindo mesmo quando seus checks antigos já foram arquivados ou apagados. Em situações que exigem uma verificação válida, pode ser necessário executar os testes novamente.
A documentação anterior já dizia que dados detalhados de checks eram arquivados depois de 400 dias e eliminados em seguida. O anúncio de agosto encurta essa referência para acompanhar a retenção do Actions, que pode ser de poucos dias e tem máximo de 90 dias em projetos públicos.
Uma explicação independente sobre a política anterior, publicada pelo RunxBuild, distingue os logs do histórico resumido da execução. O novo comunicado altera justamente essa separação ao colocar mais metadados sob o mesmo prazo, portanto textos antigos não devem ser usados para prever o comportamento depois de 1º de outubro.
O que precisa ser decidido antes de outubro
A primeira tarefa é conferir o número de dias salvo em Settings, Actions e General, ou no painel equivalente da organização. Depois, a equipe deve comparar esse prazo com contratos, auditorias, investigação de incidentes e tempo médio para descobrir falhas.
Se 90 dias forem insuficientes e o projeto for privado, o administrador pode avaliar um prazo maior dentro do limite da conta. Se o projeto for público ou se a organização impuser um teto, será necessário guardar externamente o material que precisa sobreviver além desse período.
A cópia não deve incluir segredos por descuido. Logs podem conter nomes de máquinas, caminhos, versões e, quando uma automação foi configurada de forma insegura, credenciais ou dados de clientes que nunca deveriam ter sido impressos.
Também convém testar a recuperação. Um arquivo guardado fora do GitHub só cumpre seu papel se a equipe souber relacioná-lo ao projeto, à alteração e à execução original sem depender de uma página que já foi removida.
O prazo padrão de 90 dias continuará suficiente para muitos projetos, e o GitHub apresenta a limpeza como forma de manter o Actions rápido e confiável. Para quem consulta resultados antigos, porém, o silêncio da configuração passa a ter uma consequência concreta: o histórico seguirá o valor que já estiver marcado.
Em outubro, uma execução antiga deixará de ser memória automática do projeto e passará a durar exatamente o tempo escolhido pela equipe.