GitHub Actions: provas de release além do check verde
No dia do deploy, um check verde e um link parecem bastar. Meses depois o link pode desaparecer. Lembrar que passou é diferente de explicar o que foi testado.
GitHub anunciou em 1º de outubro de 2026 que a retenção de Actions abrange checks, execuções e status. O procedimento abaixo é uma proposta operacional, não uma exigência extra do GitHub.
Confira o alcance
Registros vencidos são limpos automaticamente, incluindo checks e status de apps externos. Valem limites da organização e enterprise; o máximo público é 90 dias. Alterar o ajuste não recupera dados removidos.
Procure releases cuja única prova seja uma URL de workflow. Resultados, aprovações e hashes podem estar dispersos. Ainda será possível relacioná-los se um link sumir?
Um pacote por release
Guarde commit SHA, nome, ID e URL da execução, horário, resumo dos testes e hash do artefato. Registre quem aprovou o quê sem copiar logs secretos. Defina finalidade e acesso de leitura.
Um aprovado não explica o escopo. Documente testes parciais, runtime e lockfiles relevantes. Aponte para arquivos no commit publicado, não versões atuais.
Teste a exportação antes
Escolha um repositório e uma release. Leia ajustes e limites, salve o resumo e peça a outra pessoa que explique o deploy sem o link original.
Exportar cria outra fronteira de segurança. Defina responsável, prazo, edição e remoção de segredos. Separe evidências duráveis de material temporário de debugging.
Ausência não é automaticamente falha
Confira retenção, permissões e filtros antes de interpretar API vazia como teste nunca executado. Compare ID e provas independentes. É uma pergunta prática, não sentimento comunitário medido.
Adicione local e validade das provas ao template e releia um pacote nesta semana. Retenção maior não garante toda auditoria. O objetivo é reconstruir uma explicação defensável com escopo claro.