Pular para conteúdo

AUR-504 — O --check publica o status no commit do PR

Documento histórico do board. Pode descrever componentes removidos; para uso atual, consulte o guia do produto.

O que este card corrige

O aurumcode review --pr <numero> --repo <dono>/<projeto> --publicar --check (AUR-439) publicava o commit status aurumcode/review no commit lido de os.Getenv("GITHUB_SHA"). Num evento pull_request, o GitHub reserva GITHUB_SHA ao commit sintetico de merge que ele calcula para o PR; o override feito no workflow nao chega ao container. O status ia, portanto, para o merge commit e nunca para o HEAD revisado.

O achado medido (2026-09-15), na release dev -> main (PR #36): o auto-review publicou check "aurumcode/review" publicado no commit f9f87af...: success, onde f9f87af e o merge sintetico e cd1eb53 e o head. Uma branch protection que exige o contexto aurumcode/review marcava o head como "expected" e a PR so ficou CLEAN depois de trocar o check exigido pelo job do workflow.

O que muda

cmd/aurumcode/pr.go, no caminho --pr --check:

  • a SHA que ancora o status deixa de ser GITHUB_SHA e passa a ser o HEAD do pull request obtido da API (GetPullRequestMetadata.HeadSHA, restaurado pelo AUR-499 em internal/git/githubclient);
  • a mesma SHA de HEAD ancora o commit_id do review formal e de cada comentario inline, mantendo uma unica ancora consistente para a revisao;
  • fora do --check, o --pr continua ancorando os comentarios inline em GITHUB_SHA, exatamente como antes.

O veredito e a politica de severidade nao mudam: publishCheckStatus continua classificando error como grave com countAtOrAbove(issues, rankError) e continua publicando "failure" ou "success" pelo mesmo SetStatus. --base nao publica status nenhum: e o caminho local e nunca constroi o cliente GitHub.

Acceptance

  • AC-001: com --pr --check, mesmo quando GITHUB_SHA aponta para o merge commit, o status e publicado em /statuses/{head-da-API}.
  • AC-002: o caminho local --base continua sem publicar status e sem contatar a API do GitHub; a saida pre-existente e mantida.
  • AC-003: quando o HEAD nao pode ser determinado (erro da API, ou resposta sem head.sha), o comando falha fechado nomeando o motivo e nao publica status nenhum -- nunca cai de volta para GITHUB_SHA.

Mutacoes ceticas

  • MUT-001: voltar a usar GITHUB_SHA (o merge) para o status -> AC-001 fica RED.
  • MUT-002: suprimir a falha fechada quando falta o HEAD -> AC-003 fica RED.

Testes

  • Unit: tests/unit/AUR-504.go::TestAUR504.
  • Acceptance: tests/acceptance/AUR-504.sh, seletores all|AC-001|AC-002|AC-003|MUT-001|MUT-002; seletor desconhecido sai 64, go ausente sai 79.