Pular para conteúdo

AUR-618 — Dados de análise com retenção: pre-release e limpeza das cópias velhas

Medido

Em 2026-10-10 a lista de Releases do repositório tinha oito cópias diárias de dados de análise (22 GB) e a v1.1.0 do produto antigo como "Latest". O produto recusa dados mais velhos que analysis_data.max_age_days (padrão 7; analysis_data_stale), então toda cópia fora da janela é lixo que ocupa a lista e o espaço. As cópias antigas foram apagadas à mão e as restantes marcadas como pre-release; em 2026-10-11 e 2026-10-12 o workflow voltou a publicar cópias sem a marca, porque publish.sh não a passava.

Entregue

  • scripts/artifacts/publish.sh: release create e release edit levam --prerelease (além de --latest=false, que já existia). O fluxo rascunho → preenchido → publicado não muda.
  • scripts/artifacts/retain.sh (novo): lista as releases publicadas (gh release list --json tagName,publishedAt,isDraft), ordena da mais nova para a mais velha, considera só as tags analysis-data/*, preserva as --keep mais novas (padrão 3) e apaga, com gh release delete --yes --cleanup-tag (release e tag), as publicadas antes de now - --days (padrão 7). --dry-run só lista. Rascunhos ficam de fora (um rascunho é uma cópia que publish.sh não terminou). Argumentos inválidos saem com 64 antes de qualquer chamada ao gh. A data de publicação é a do GitHub (publishedAt, UTC ISO 8601 de largura fixa, comparada como texto), não a da tag, para que toda release tenha uma idade e o filtro de prefixo seja a única coisa que protege as releases do produto.
  • .github/workflows/analysis-data.yml: inputs retention_days (7) e keep_at_least (3) no workflow_dispatch; passo "Delete the copies the runtime no longer accepts" logo depois de "Publish immutable release", no mesmo job (contents: write), com os valores em variáveis de ambiente e os padrões quando o disparo é agendado (inputs.* || '7').
  • docs/configuration.md, subseção "O que a lista de Releases mostra": produto vs cópias, pre-release, janela e mínimo, inputs, --dry-run, prefixo.

Prova

  • tests/acceptance/AUR-618.sh all com um gh falso no PATH que registra cada chamada e responde release list com uma lista propositalmente fora de ordem:
  • AC-001: asserção estática das duas linhas de publish.sh e da ordem dos passos no workflow (publish antes de retain, inputs ligados), e uma publicação real de um dist montado no teste, com --prerelease nas duas chamadas registradas.
  • AC-002: padrões (apaga as três cópias fora da janela além das três mais novas, nunca v1.1.0, v1.0.1 ou beta), --days 1 --keep 1 (a cópia publicada há exatamente um dia não é mais velha que a janela), piso de 3 com todas velhas, menos cópias que o piso, --dry-run sem apagar, e argumentos inválidos sem chamar o gh.
  • AC-003: frases da subseção nova em docs/configuration.md.
  • MUT-001: cópia de retain.sh sem a linha do filtro de prefixo apaga v1.0.1; o cenário AC-002 fica vermelho e a mutação é descartada.
  • go test ./internal/artifacts/... continua verde: os testes do AUR-533 conferem o fluxo rascunho → publicado e a ordem dos jobs do workflow.
  • Aceite selado: ./.board/bin/oci-run --profile go-unit-offline-v1 --card AUR-618.

Limites

  • A retenção não roda quando a publicação falha (o passo vem depois e o job para no primeiro erro): uma cópia velha sobrevive até o próximo dia bom.
  • Rascunhos deixados por uma publicação interrompida não são apagados.