User story
Como o watchdog, eu quero saber o estado de refs que o GitHub reporta para cada repositório da
organização, para poder alertar por comparação exata em vez de por data de push.
Acceptance criteria
Migration 024
POST /api/ingest/repo-state
A distinção na listagem
Por que as três coisas na mesma issue
Cada coluna tem um leitor: o last_refs_digest é o que torna a checagem 1 do watchdog exata; o
last_pushed_at é a idade que a mensagem de alerta mostra; o last_seen_at diz a idade do próprio
censo.
E o censo não é inócuo: ele cria linha para repositório que nunca ingeriu nada, e
getOrgReposSummary parte de todas as linhas da tabela
(platform/lib/queries/temporal.ts:216-228). Sem a distinção na listagem, /[tenant]/repos passaria a
listar os 598, quase todos sem métrica. Mergear a migration sem a mudança na listagem quebra uma
página que já está em uso — por isso as três vêm juntas.
O nome é a chave, e tem de ser o mesmo das duas pontas
A tabela é UNIQUE(organization_id, name). Se as duas pontas divergirem, cada repositório vira duas
linhas — uma com censo e sem análise, outra com análise e sem censo —, a checagem 1 compara o
last_refs_digest de uma com o digest da outra e alerta para os 598.
Isto não é estado de fila
Nada aqui decide o que analisar: a seleção continua sendo o digest de refs contra analysis_runs. São
três colunas de observação, numa tabela que já existe. O censo rende uma segunda coisa de graça: é o
denominador da métrica de cobertura da §7, que antes não tinha de onde sair.
Se encaixa em qual estágio?
Stage 2 — Platform: repo/org views, health scoring.
Links
User story
Como o watchdog, eu quero saber o estado de refs que o GitHub reporta para cada repositório da
organização, para poder alertar por comparação exata em vez de por data de push.
Acceptance criteria
Migration
024alter table repositories add column last_pushed_at timestamptz;alter table repositories add column last_refs_digest text;alter table repositories add column last_seen_at timestamptz;POST /api/ingest/repo-stateupsertpor repositório/api/ingestresolve porname(
route.ts:104-109); onameWithOwnerfica dentro do workerA distinção na listagem
/[tenant]/reposdistingue conhecido pelo censo de já analisado, pelolast_seen_atapi/tenants/[tenant]/repo-counte a páginaconnectcontinuam decidindohasReposde forma coerentePor que as três coisas na mesma issue
Cada coluna tem um leitor: o
last_refs_digesté o que torna a checagem 1 do watchdog exata; olast_pushed_até a idade que a mensagem de alerta mostra; olast_seen_atdiz a idade do própriocenso.
E o censo não é inócuo: ele cria linha para repositório que nunca ingeriu nada, e
getOrgReposSummaryparte de todas as linhas da tabela(
platform/lib/queries/temporal.ts:216-228). Sem a distinção na listagem,/[tenant]/repospassaria alistar os 598, quase todos sem métrica. Mergear a migration sem a mudança na listagem quebra uma
página que já está em uso — por isso as três vêm juntas.
O nome é a chave, e tem de ser o mesmo das duas pontas
A tabela é
UNIQUE(organization_id, name). Se as duas pontas divergirem, cada repositório vira duaslinhas — uma com censo e sem análise, outra com análise e sem censo —, a checagem 1 compara o
last_refs_digestde uma com o digest da outra e alerta para os 598.Isto não é estado de fila
Nada aqui decide o que analisar: a seleção continua sendo o digest de refs contra
analysis_runs. Sãotrês colunas de observação, numa tabela que já existe. O censo rende uma segunda coisa de graça: é o
denominador da métrica de cobertura da §7, que antes não tinha de onde sair.
Se encaixa em qual estágio?
Stage 2 — Platform: repo/org views, health scoring.
Links