Depois do push, o Gitea criou `ci.yml #3` e `runner-check.yml #4`, ambos em
Waiting com a mesma mensagem de runner ausente. Com o `ci.yml #2` anterior, são
três runs enfileirados esperando o runner — nenhum precisa ser republicado.
Duas correções de expectativa que valem registro:
O `concurrency` que eu declarei para evitar fila não tem efeito nesta versão: o
run 667 deveria ter cancelado o 666, do mesmo grupo, e não cancelou. A fila vai
crescer a cada push até existir runner. Fica documentado para ninguém contar
com um cancelamento que não acontece.
A barra lateral de Workflows mostra apenas `ci.yml` porque lista o que existe
na branch padrão, onde `runner-check.yml` ainda não está. Isso não impediu o
run de ser criado a partir de `homologacao`.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
O push para o Gitea criou o run, mas ele ficou em Waiting: a mensagem da
instância é "No matching online runner with label: ubuntu-latest". A falha é na
atribuição do job, não no enfileiramento — o gatilho funcionou e a branch está
contemplada. O endpoint /actions/tasks devolvia lista vazia porque lista tasks
aceitas por runner, não runs criados, e foi isso que confundiu a leitura.
Com o diagnóstico fechado, duas coisas importam antes de um runner existir.
Primeira: este repositório é público e o CI dispara em pull_request. Sem
guarda, um fork traria código de terceiro para rodar na máquina do runner, com
Docker à disposição. Os três jobs do ci.yml e o runner-check passam a exigir
que o PR venha da própria origem; push continua rodando normalmente. Também
entram `permissions: contents: read` e `concurrency` por ref, para não
acumular fila de runs esperando runner.
Segunda: `runner-check` é o primeiro workflow a rodar quando o runner subir.
Não faz checkout, não instala dependência, não usa segredo e não toca rede
externa. Só confirma a ligação e inventaria node, npm, docker, psql e python3
— o job `services` precisa de psql e a jornada assíncrona precisa de python3,
e é melhor descobrir isso num workflow de dez segundos.
A documentação registra a evidência (runs 666 em Waiting e 584 cancelado),
recomenda act_runner 0.6.1-dind-rootless com escopo de repositório, e explica
por que Docker-in-Docker em vez do socket do host: num repositório público,
montar o socket entregaria o Docker da máquina ao workflow. Fica registrado
também que os ambientes de aprovação manual do deploy são conceito do GitHub e
não têm equivalente no Gitea.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Havia dois runbooks sobrepostos, escritos para o piloto, e nenhum documento do
ambiente de homologação.
- `20-homologacao-runbook.md` consolida os dois e cobre DNS, TLS, Nginx,
Supabase de homologação, banco com a decisão do shim, bucket privado,
containers, worker, observabilidade, flag, rollback, diagnóstico e smoke.
Os dois runbooks antigos ficam no repositório marcados como histórico,
preservando o registro das decisões.
- Rollback de imagem com comandos: identificar o que está no ar, listar tags,
desligar a flag antes de trocar, subir só web e worker com `--no-deps`,
conferir saúde, religar a flag. As migrations de segurança — RLS e auditoria
append-only — estão declaradas sem caminho de volta: desfazê-las afrouxa o
isolamento entre workspaces, então um rollback que precise disso está errado
por definição.
- `21-checklist-validacao.md` separa o que foi executado do que depende de
infraestrutura, com a evidência de cada item e a tabela dos quatro defeitos
encontrados. Nada está marcado PASS por inspeção de código.
- ADR 0007 registra o ambiente lógico e a autenticação de homologação, com as
alternativas descartadas e o motivo.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
O módulo usa a identidade Supabase, isola cada workspace e registra storage, TTL, runner e biblioteca XLSX como decisões ainda abertas.
Co-authored-by: Cursor <cursoragent@cursor.com>
Ferraz Fagundes